SQL插入速度的变化

Question

我正在处理的脚本旨在更新数据库表,该数据库表记录了使用国家和所有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,主键

registry - varchar(7)

代码 - varchar(2)

type - varchar(4)

start - varchar(15)

value - int

日期 - 日期时间

status - varchar(10)

Answer 1

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'

查看生产环境的活动写入磁盘的数据量和变化。

启动脚本并等待，直到您注意到写入磁盘的字节数有所增加。如果编写的步骤几乎是一个恒定值（高于正常的生产使用），那么它就是颠簸和交换，如果它是有节奏的，那么它只是为了提交而编写。