mysql batchinsert_使用batch insert解决MySQL的insert吞吐量问题_MySQL

最新推荐文章于 2024-06-28 17:15:15 发布

句子院

最新推荐文章于 2024-06-28 17:15:15 发布

阅读量819

点赞数

文章标签： mysql batchinsert

本文链接：https://blog.csdn.net/weixin_33547979/article/details/113274332

版权

最近使用了一个非常简单易用的方法解决了业务上的一个insert吞吐量的问题，在此总结一下。

首先我们明确一下，insert吞吐量其实并不是指的IPS(insert per second)，而是指的RPS(effect rows per second)。

其次我们再说一下batch insert，其实顾名思义，就是批量插入。这种优化思想是很基本的，MySQL中最出名的应用就是group commit。

简单的来说，就是将SQL A 变成 SQL BSQL A : insert into table values ($values);SQL B : insert into table values ($values),($values)...($values);

下面，我们来看看这种异常简单的改动会带来什么样子的变化。

测试环境交代：单id的表结构，10w个int values，本地使用socket连接MySQL server，使用shell单进程测试。

首先，我们看下使用SQL A将10w个int values插入到test表中所需的耗时，耗时1777秒。real 29m37.090suser 9m11.705ssys 5m0.762s

然后，我们看下使用SQL B(每次insert，插入10 values)将10w个int values插入到test表中所需的耗时，耗时53秒real 0m53.871suser 0m19.455ssys 0m6.285s

这是整整近33倍的时间提升。这部分性能提升的原因在于以下几点：

1、每次和MySQL server建立连接都需要经过各种初始化、权限认证，语法解析等等多个步骤，需要消耗一定的资源。

2、更新一个values和更新n个values耗时基本一致。(下面对比一下insert 单values核insert 10 values的profile耗时)单values：

+------------------------------+----------+| Status | Duration |+------------------------------+----------+| starting | 0.000056 || checking permissions | 0.000010 || Opening tables | 0.000034 || System lock | 0.000010 || init | 0.000011 || update | 0.000061 || Waiting for query cache lock | 0.000003 || update | 0.000015 || end | 0.000003 || query end | 0.000053 || closing tables | 0.000009 || freeing items | 0.000021 || logging slow query | 0.000002 || cleaning up | 0.000003 |+------------------------------+----------+

10 values：+------------------------------+----------+| Status | Duration |+------------------------------+----------+| starting | 0.000061 || checking permissions | 0.000008 || Opening tables | 0.000027 || System lock | 0.000008 || init | 0.000012 || update | 0.000073 || Waiting for query cache lock | 0.000003 || update | 0.000010 || end | 0.000008 || query end | 0.000053 || closing tables | 0.000010 || freeing items | 0.000021 || logging slow query | 0.000002 || cleaning up | 0.000003 |+------------------------------+----------+

但是，是否values积攒的越多，效率越高吗？答案自然是否定的，任何优化方案都不会是纯线性的，肯定会在某个条件下出现拐点。

我们按照不同的values number进行测试，分别为1、10、50、100、200、500、1000、5000、10000.

从下图我们可以看出，随着values number的增加，耗时先是急剧下降，从1777s变成53s，然后在增加values number就不会有太大的变化，直到values number超过200，最后的10000个values number耗时达到了2分钟。