最近遇到過生產上的資料丟失問題，看到大家各種分析程式碼，然後我發現很多人認為事物提交了就認為資料不會丟失！！！。。。我只能說這是公司沒有DBA，或者說大家不能深層次理解mySQL原理的悲哀！

針對此，特意寫了這篇部落格！（理解不深刻不準確之處，敬請指出）

現象

正常情況下，我們會將一系列增，刪，改操作寫在一個事物中，也就是一個原子操作，那麼理論上這一系列的操作，要麼會同時成功，要麼會同時失敗（回滾）！

但實際上呢，資料庫返回失敗，那麼這一系列資料庫操作肯定都不會成功，但如果資料庫返回成功，那麼絕大部分情況都會會全部成功，但也有可能會部分成功，或者全部不成功。這也就是資料丟失。

mysql的資料丟失大致可以分為：

儲存引擎層面丟失資料

在實際專案中，我們一般接觸到的是支援事物的InnoDB儲存引擎，此處只講innoDB儲存引擎的資料丟失。

InnoDB預設開啟內部的XA事物（實現方式是基於redo log和undo log），也就是採用日誌先行的策略。在未開啟binlog的情況下，資料變更（資料的增，刪，改操作）會在記憶體中操作，並將事物順序寫入到redo log中，這時就會認為事物已經完成，響應事物提交成功。然後在一定條件下，才將記憶體中的資料合併到磁碟中。

所以，在持久化到磁碟的過程中，如果伺服器宕機等導致記憶體中的資料丟失，資料也就會丟失。不過這種資料丟失是可以通過 recovery 重做日誌，找回資料的。

      這就是前面描述的資料丟失，根本原因就是記憶體中的資料沒有及時重新整理到磁碟中。 所以InnoDB有一個特別的引數用於設定這兩個快取的重新整理： innodb_flush_log_at_trx_commit.

      預設，innodb_flush_log_at_trx_commit=1，表示在每次事務提交的時候，都把log buffer刷到檔案系統中去，並且呼叫檔案系統的“flush”操作將快取重新整理到磁碟上去。這樣的話，資料庫對IO的要求就非常高了，如果底層的硬體提供的IOPS比較差，那麼MySQL資料庫的併發很快就會由於硬體IO的問題而無法提升。

      為了提高效率，保證併發，犧牲一定的資料一致性。

      innodb_flush_log_at_trx_commit=0時，每隔一秒把log buffer刷到檔案系統中去，並且呼叫檔案系統的“flush”操作將快取重新整理到磁碟上去。這樣的話，可能丟失1秒的事務資料。

      innodb_flush_log_at_trx_commit=2時，在每次事務提交的時候會把log buffer刷到檔案系統中去，但是每隔一秒呼叫檔案系統的“flush”操作將快取重新整理到磁碟上去。如果只是MySQL資料庫掛掉了，由於檔案系統沒有問題，那麼對應的事務資料並沒有丟失。只有在資料庫所在的主機作業系統損壞或者突然掉電的情況下，資料庫的事務資料可能丟失1秒之類的事務資料。這樣的好處就是，減少了事務資料丟失的概率，而對底層硬體的IO要求也沒有那麼高(log buffer寫到檔案系統中，一般只是從log buffer的記憶體轉移的檔案系統的記憶體快取中，對底層IO沒有壓力)。MySQL 5.6.6以後，這個“1秒”的重新整理還可以用innodb_flush_log_at_timeout 來控制重新整理間隔。

   在大部分應用環境中，應用對資料的一致性要求並沒有那麼高，所以很多MySQL DBA會設定innodb_flush_log_at_trx_commit=2，這樣的話，資料庫就存在丟失最多1秒的事務資料的風險。

mysql還存在另外一種資料丟失，資料庫的複製丟失資料。

主從複製層面丟失資料

mysql的複製並不能很好地從伺服器宕機，磁碟損壞、記憶體或網路錯誤中恢復，這時一般得從某個點開啟重啟複製。

       這些情況包括：主庫意外關閉、備庫意外關閉、主庫上的二進位制日誌損壞、備庫上的中繼日誌損壞、二進位制日誌與InnoDb事物日誌不同步等。