mysql大量数据插入慢的问题

这个是需要做一些设置的。主要设置 rewriteBatchedStatements参数。原理如下：

MySQL Jdbc驱动在默认情况下会无视executeBatch()语句，把我们期望批量执行的一组sql语句拆散，一条一条地发给MySQL数据库，直接造成较低的性能。

只有把rewriteBatchedStatements参数置为true, 驱动才会帮你批量执行SQL (jdbc:mysql://ip:port/db?rewriteBatchedStatements=true)。不过，驱动具体是怎么样批量执行的？　你是不是需要看一下内幕，才敢放心地使用这个选项？ 下文会给出答案。

另外，有人说rewriteBatchedStatements只对INSERT有效，有人说它对UPDATE/DELETE也有效。为此我做了一些实验（详见下文），结论是： 这个选项对INSERT/UPDATE/DELETE都有效，只不过对INSERT它为会预先重排一下SQL语句。

注：本文使用的mysql驱动版本是5.1.12

实验记录：未打开rewriteBatchedStatements时

未打开rewriteBatchedStatements时，根据wireshark嗅探出的mysql报文可以看出，

batchDelete(10条记录) => 发送10次delete 请求

batchUpdate(10条记录) => 发送10次update 请求

batchInsert(10条记录) => 发送10次insert 请求

也就是说，batchXXX()的确不起作用

实验记录：打开了rewriteBatchedStatements后

打开rewriteBatchedStatements后，根据wireshark嗅探出的mysql报文可以看出

batchDelete(10条记录) => 发送一次请求，内容为”delete from t where id = 1delete from t where id = 2delete from t where id = 3….”

batchUpdate(10条记录) => 发送一次请求，内容为”update t set … where id = 1update t set … where id = 2update t set … where id = 3 …”

batchInsert(10条记录) => 发送一次请求，内容为”insert into t (…) values (…) , (…), (…)”

对delete和update，驱动所做的事就是把多条sql语句累积起来再一次性发出去；而对于insert，驱动则会把多条sql语句重写成一条风格很酷的sql语句，然后再发出去。 官方文档说，这种insert写法可以提高性能（”This is considerably faster (many times faster in some cases) than using separate single-row INSERT statements”）

一个注意事项

需要注意的是，即使rewriteBatchedStatements=true, batchDelete()和batchUpdate()也不一定会走批量： 当batchSize <= 3时，驱动会宁愿一条一条地执行SQL。所以，如果你想验证rewriteBatchedStatements在你的系统里是否已经生效，记得要使用较大的batch.

更多细节看这个帖子：

blog.yemou.net/article/query/info/tytfjhfascvhzxcyt397

MYSQL_OPT_READ_TIMEOUT 是 MySQL c api 客户端中用来设置读取超时时间的参数。在 MySQL 的官方文档中，该参数的描述是这样的：

MYSQL_OPT_READ_TIMEOUT (argument type: unsigned int *)The timeout in seconds for each attempt to read from the server. There are retries if necessary, so the total effective timeout value is three times the option value. You can set the value so that a lost connection can be detected earlier than the TCP/IPClose_Wait_Timeout value of 10 minutes.

也就是说在需要的时候，实际的超时时间会是设定值的 3 倍。但是实际测试后发现实际的超时时间和设置的超时时间一致。

而具体什么时候发生三倍超时，在文档中没有找到。所以对 MySQL 5.7.20 的源码进行了一些分析。

使用 GDB 调试代码找了实际与 mysql server 通信的代码，如下：

请点击输入图片描述

其中 vio_read() 函数中，使用 recv 和 poll 来读取报文和做读取超时。net_should_retry() 函数只有在发生 EINTR 时才会返回 true。从这段代码来看是符合测试结果的，并没有对读取进行三次重试。只有在读取 *** 作被系统中断打断时才会重试，但是这个重试并没有次数限制。

从上面代码的分析可以看出，代码的逻辑和文档的描述不符。于是在一顿搜索后，找到了一个 MySQL 的 BUG(Bug #31163)。该 BUG 报告了在 MySQL 5.0 中，MySQL c api 读取的实际超时时间是设置的三倍，与现有文档描述相符。于是对 MySQL 5.0.96 的代码又进行分析。

同样使用 GDB 找到了通信部分的代码。这次找到了重试三次的代码，如下：

请点击输入图片描述

这个版本的 MySQL api 的读写超时是直接使用的 setsockopt 设置的。第一次循环，在 A 点发生了第一次超时（虽然注释写的非阻塞，但是客户端的连接始终是阻塞模式的）。然后在 B 点将该 socket 设置为阻塞模式，C 点这里重置 retry 次数。由于设置了 alarm 第二次以后的循环会直接进入 D 点的这个分支，并且判断循环次数。作为客户端时net->retry_count 始终是 1，所以重试了两次，共计进行了 3 次 vioread 后从 E 点退出函数。

由上面的分析可知，MySQL 文档对于该参数的描述已经过时，现在的 MYSQL_OPT_READ_TIMEOUT 并不会出现三倍超时的问题。而 Bug #31163 中的处理结果也是将文档中该参数的描述更新为实际读取超时时间是设定时间的三倍。也许是 MySQL 的维护者们在后续版本更新时忘记更新文档吧。

估计是你使用的红旗linux5板本号和mysql的板本号不兼容，上面的参数都是红旗linux5的错误报文，你可以下载红帽子linux吧。直接解决这个难度很大，要你安装这个又哪安装哪个，估计也不能解决问题。你可以电驴下下载.

---