修改innodb_flush_log_at_trx_commit参数提升insert性能

最近，在一个系统的慢查询日志里发现有个insert操作很慢，达到秒级，并且是比较简单的SQL语句，把语句拿出来到mysql中直接执行，速度却很快。

这种问题一般不是SQL语句本身的问题，而是在具体的应用环境中，由于并发等原因导致的。最可怀疑的地方就是在等待表级锁。

加上监控的日志来看，很多SQL是在同一时间完成的，下面的第三列是结束时间，第四列是开始时间：

14:27:30 bizId30905 1355812050  1355812045
14:27:30 bizId28907 1355812050  1355812043
14:27:30 bizId30905 1355812050  1355812047
14:27:30 bizId17388 1355812050  1355812040
14:27:30 bizId40563 1355812050  1355812044
14:27:30 bizId15477 1355812050  1355812048
14:27:30 bizId32588 1355812050  1355812048

但是通过应用的分析来看，并不存在表级锁的地方，而insert自身的操作也只是对要插入的记录本身加锁，不会影响其他并发的insert操作。

没有更好的办法，只能在MySQL写入磁盘的性能上考虑，MySQL有个innodb_flush_log_at_trx_commit参数，用来配置flush log到磁盘的时机，具体点说，是从log buffer写到log file，并写入到磁盘上的时机。这个参数的默认值是1，即每次事务提交的时候会把日志刷到磁盘，而频繁的insert操作就会引起flush log操作的不断积累，进而引发性能问题。在应用数据可接受的前提下，可以把这个值改成0，就是每秒才操作一次。修改后潜在的问题是，在事务已经提交的情况下，如果尚未写入磁盘的时候发生故障，可能丢失数据。

MySQL官网对此参数的描述如下：

If the value of innodb_flush_log_at_trx_commit is 0, the log buffer is written out to the log file once per second and the flush to disk operation is performed on the log file, but nothing is done at a transaction commit. When the value is 1 (the default), the log buffer is written out to the log file at each transaction commit and the flush to disk operation is performed on the log file. When the value is 2, the log buffer is written out to the file at each commit, but the flush to disk operation is not performed on it. However, the flushing on the log file takes place once per second also when the value is 2. Note that the once-per-second flushing is not 100% guaranteed to happen every second, due to process scheduling issues.

The default value of 1 is required for full ACID compliance. You can achieve better performance by setting the value different from 1, but then you can lose up to one second worth of transactions in a crash. With a value of 0, any mysqld process crash can erase the last second of transactions. With a value of 2, only an operating system crash or a power outage can erase the last second of transactions. InnoDB‘s crash recovery works regardless of the value.

其他角度的优化办法：

如果是MyISAM存储引擎，可以使用insert delay的方式来提高性能，其原理是MySQL自身会在内存中维护一个insert队列，在实际表空闲的时候insert数据。

从应用的角度，批量提交也是解决问题的办法，当然要在应用场景许可的前提下。

参考：

http://www.banping.com/2012/12/19/innodb_flush_log_at_trx_commit/