MySQL中的命令列mysqldump做為常用的資料備份工具，雖說效能稍差，但優在易於呼叫，從長期應用的情況來看其表現也相當穩定，並且老實講MySQL資料庫下邏輯備份確實沒有太多選擇，因此mysqldump應用極為廣泛，三思本人也是經常使用這個命令倒騰資料，整體感覺是個挺美好的東西，不過上週遭遇一次案例，認識到我對mysqldump的認識還有不足，記錄下來，供有心的朋友參考。 事情是介個樣子的，mysqldump命令常規方式建立備份拉到某機器上恢復，恢復執行很成功，一條錯誤資訊都沒看著，但等恢復完登入到資料庫中一瞅，你猜怎麼地，資料不全~~ 第一反應當然是檢視備份檔案，經過檢查，果然，恢復操作確實沒有問題，因為備份集中的內容就不全，那麼，為什麼備份集內容不全呢~~ 幸好原有執行場景均有記錄，分析發現，原來是在匯出某個檢視物件時報錯，mysqldump自動中止，因此所有該物件之後的就都沒備份了~ 這種情況模擬重現很簡單，操作如下： mysql> create table j1 (id int,vl varchar(100)); mysql> create view j1_view as select * from j1;
mysql> rename table j1 to j2; # mysqldump --tables j1 j1_view > bak.sql mysqldump: Got error: 1356: View 'test.j1_v' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them when doing LOCK TABLES 建立備份時，view物件引用的表物件不存在，執行LOCK TABLES失敗，於是mysqldump就中止了，這其實真不怪mysqldump，因為mysqldump執行過程中遇到任何問題，預設情況下都是直接退出。 那麼怎麼處理這種情況呢，兩種思路： １、修正無效的檢視，這點可以通過information_schema.views.IS_UPDATABLE列來判斷，當IS_UPDATABLE列值為NO時，說明該檢視狀態異常，需要處理了； ２、執行mysqldump時附加--force引數，該引數功能是當遇到錯誤時忽略，繼續執行後面的操作； 這個引數提供類似ORACLE資料庫中exp命令的ignore=y引數的功能，事實上在ORACLE資料庫中執行exp時通常都會指定ignore，對應到MySQL資料庫，我想在執行mysqldump命令列過程中，--force引數也應做為必備引數呼叫。