SQL插入速度的变化
我正在处理的脚本旨在更新数据库表，该表记录了使用国家和所有IP地址（或几乎所有IP地址）的状态。 目前我保持简单，只从5个RIR（地区互联网注册管理机构）获取数据并将其保存到我的数据库。
最初速度是不切实际的，但是通过减少日志中的信息量并将SQL插入组分组为1000并使用单个查询来显着改善。 但是，现在运行脚本时，SQL插入的速度会有很大的变化，我想知道是否有人知道原因。
以下是我记录的一些速度。 在测试中，我分离出了在PHP中执行脚本迭代所需的时间以及应用sql语句所花费的时间，我没有在下面的列表中包含PHP时间，因为效果可以忽略不计; 即使是最大的数据块也不会超过1秒。
测试速度 （插入的数据行数始终保持不变）
测试1总SQL执行时间：33秒
测试2总SQL执行时间：72秒
测试3总SQL执行时间：78秒
其他测试继续在〜30秒和〜80秒之间波动。
我有两个问题：
1）我应该接受这些差异作为世界的方式，还是有理由？
2）我把约185000行插入到一个查询中感到紧张。 我有什么理由避免使用这些插入的查询吗？ 我还没有使用过此前一次保存的大量数据。
谢谢
__
数据库表如下。
Sorage Engine - InnoDB
列：
id - int，主键
注册表 - varchar（7）
代码 - varchar（2）
类型 - varchar（4）
开始 - varchar（15）
value - int
日期 - 日期时间
状态 - varchar（10）
1) Should I accept these disparities as the way of the world, or is there a reason for them?
速度变化可能是由于使用磁盘IO的竞争进程 - 等待资源。 如果这是一台生产服务器而不是孤独的测试服务器，那么当然其他一些进程正在请求访问该磁盘。
2) I felt nervous about lumping the ~185000 row inserts into one query. Is there any reason I should avoid using one query for these inserts? I've not worked with this amount of data being saved at one time before.
您还应该将插入分成X个插入组，并将每个组插入一个事务。
除了实验性以外，以其他方式确定X的价值很难。
将插入分组到事务中可确保仅在每次事务（而不是每次（自动提交）插入后）将数据写入（提交）到磁盘。
这对磁盘IO有很好的影响，如果将多个插入组合到一个事务中，它可能会对可用内存造成不良影响。 如果未提交的数据量对于当前内存来说太大，则DBMS将开始将数据写入内部日志（在磁盘上）。
所以X取决于插入的数量，与每个插入相关的数据量，允许的内存/用户/会话参数。 还有很多其他的东西。
percona有一些很酷的（免费）工具。 他们帮助您监视数据库活动。
你也可以看看vmstat watch -n.5'vmstat'
查看生产环境活动写入磁盘的数据量和变化情况。
向上启动您的脚本并等待，直到您注意到写入磁盘的字节数增加。 如果编写这个步骤几乎是一个恒定的值（高于正常的生产使用），那么它是颠簸和交换，如果它是有节奏的，那么它只是为提交而写。
链接地址: http://www.djcxy.com/p/11279.html