關於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、一、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