mysql大量数据插入慢的问题

Posted 2023-04-29

我现在有大量的insert into 数据不知道怎么执行起来才不是很慢

这个是需要做一些设置的。主要设置 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 = 1; delete from t where id = 2; delete from t where id = 3; ….”
batchUpdate(10条记录) => 发送一次请求，内容为”update t set … where id = 1; update t set … where id = 2; update 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 参考技术A 用第三方介质导入，速度比你执行insert语句快。比如用EXCEL或者ACCESS表格充当介质。

关于Mysql表InnoDB下插入速度慢的解决方案

最近做了 server_log 日志数据库记录,仅仅插入,由平台来获取数据进行分析的需求。

但是内部反馈插入数据库记录非常耗时，我就很纳闷了，一个insert怎么会 30-50ms 呢？按说应该在 0.5ms 以内的；

经过分析，发现是InnoDB数据库的Row_Format格式问题，改为MyISAM表就可以了，但是InnoDB是支持事务的，一般是推荐InnoDB的，好奇为什么。

而且InnoDB的表，只能选择 COMPACT 和REDUNDANT 两种行格式（RoW_FORMAT）。

经过搜索获得：

innodb_flush_log_at_trx_commit

该参数控制重做日志写入磁盘的过程。我们知道 InnoDB 使用“Write Ahead Log”策略来避免数据丢失问题，即依靠重做日志来保证数据能在丢失后进行恢复。因此，InnoDB 重做日志的持久化非常重要。

该参数的有效值有 0、1、2：

0：事务提交时，不将重做日志缓冲写入磁盘，而是依靠 InnoDB 的主线程每秒执行一次刷新到磁盘。因此如果 MySQL 发生宕机，那么就有可能丢失一部分事务。

1：事务提交时，会将重做日志缓冲写入磁盘，并且立即刷新（fsync()）。注意，因为操作系统的“延迟写”特性，此时的刷入只是写到了操作系统的缓冲区中，因此执行同步操作才能保证一定持久化到了硬盘中。

2：事务提交时，会将重做日志缓冲写入磁盘，但是不会立即进行刷新操作，因此只是写到了操作系统的缓冲区。此时若操作系统发生宕机而没有即使的同步，也可能会丢失一部分数据。

可以看到，只有1才能真正地保证事务的持久性，但是由于刷新操作 fsync() 是阻塞的，直到完成后才返回，我们知道写磁盘的速度是很慢的，因此 MySQL 的性能会明显地下降。如果不在乎事务丢失，，0和2能获得更高的性能。
--------------------- 
作者：yyyiue 
来源：CSDN 
原文：https://blog.csdn.net/stfphp/article/details/57413894 
版权声明：本文为博主原创文章，转载请附上博文链接！

经过测试，修改值为0或者2 后，插入速度果然提升了，1.4秒可以插入2W条记录，平均<1ms满足需求.

 

 

参考链接：

MySQL 重要参数 innodb_flush_log_at_trx_commit 和 sync_binlog