公司開發人員在測試環境中執行一條 insert 語句時，需要花費 10 幾秒才可以執行成功。查看測試環境數據庫性能、數據量、死鎖等信息，均為發現異常。最后通過修改日志寫入方式解決此問題。

1. 修改辦法

修改/etc/my.cnf文件，將 innodb_flush_log_at_trx_commit = 1改為0， 但這樣就要承擔數據庫Crash后，1秒內未存儲到數據庫數據丟失可能的風險。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.

2. 參數說明

• 0：log buffer將每秒一次地寫入log file中，并且log file的flush(刷到磁盤)操作同時進行。該模式下在事務提交的時候，不會主動觸發寫入磁盤的操作
• 1：每次事務提交時MySQL都會把log buffer的數據寫入log file，并且flush(刷到磁盤)中去，該模式為系統默認
• 2：每次事務提交時MySQL都會把log buffer的數據寫入log file，但是flush(刷到磁盤)操作并不會同時進行。該模式下，MySQL會每秒執行一次 flush(刷到磁盤)操作
  

3. 注意事項

當設置為0時，該模式速度最快，但不太安全，mysqld進程的崩潰會導致上一秒鐘所有事務數據的丟失。

當設置為1時，該模式是最安全的，但也是最慢的一種方式。在mysqld 服務崩潰或者服務器主機crash的情況下，binary log 只有可能丟失最多一個語句或者一個事務。

當設置為2時，該模式速度較快，也比0安全，只有在操作系統崩潰或者系統斷電的情況下，上一秒鐘所有事務數據才可能丟失。

innodb_flush_log_at_trx_commit和sync_binlog 兩個參數是控制MySQL 磁盤寫入策略以及數據安全性的關鍵參數，當兩個參數都設置為1的時候寫入性能最差，推薦做法是innodb_flush_log_at_trx_commit=2，sync_binlog=500 或1000。

到此這篇關于MySQL刪除和插入數據很慢的問題解決的文章就介紹到這了,更多相關MySQL刪除和插入數據很慢內容請搜索腳本之家以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持腳本之家！