在上篇《MySQL--當mysqldump --single-transaction遇到alter table》中測試發現，在MySQL 5.6版本中，如果在mysqldump期間修改表，可能會導致mysqldump報錯，而該結論與同事的執行現象不符，因此在MySQL 5.5版本中進行下測試。 測試 ...
在上篇《MySQL--當mysqldump --single-transaction遇到alter table》中測試發現，在MySQL 5.6版本中，如果在mysqldump期間修改表，可能會導致mysqldump報錯，而該結論與同事的執行現象不符，因此在MySQL 5.5版本中進行下測試。
測試環境：
MySQL 5.5.14
在資料庫testdb01下有表tb1001，當前表中存有兩條數據：
##=========================================================##
發現竟然返回的是空集，沒有任何報錯。
這也就合理解釋我同事操作的現象：在mysqldump過程中，修改表結構，修改操作沒有被阻塞，mysqldump操作也”正常完成“。
由於SELECT /*!40001 SQL_NO_CACHE */ * FROM `tb1001`操作沒有返回錯誤也沒有返回數據，mysqldump進程會將tb1001當做一個空表來處理，然後繼續導出後面的表直至導出所有的表然後返回執行成功的狀態。但導出的備份已經缺失tb1001的數據，如果恰好採用該備份去恢複數據，那麼必然最終導致“數據丟失”。
解決辦法：
在對MySQL 5.5版本進行修改表操作前，先檢查當前伺服器是否在進行mysqldump操作，避免兩者並行執行。
如果對mysqldump已經導出過的表進行修改操作，修改操作會被阻塞，直到mysqldump結束，該情況與MySQL 5.6版本一致。
##=========================================================================================##
總結：
對於MySQL 5.5版本，mysqldump與表修改操作同時執行：
如果修改表操作在 ”mysqldump開啟後但還未導出修改表數據前“ 的時間段內開始，則修改表操作成功完成，而mysqldump不會執行失敗，但是無法正常導出修改表的數據；
如果修改表操作在 “mysqldum已導出修改表數據但還未結束mysqldump操作前”的時間段內開始，則修改表操作被阻塞，mysqldum能成功完成，在mysqldump操作完成後修改表操作方可正常執行。
對於MySQL 5.5版本，應該避免mysqldump和修改表操作同時進行，以避免備份丟失修改表的數據，造成數據不一致！
##=========================================================================================##
