資料庫裡誤刪了記錄，還能還原回來嗎：一次從 binlog 撈資料的實錄

週五下午，一個客戶的工廠群裡炸了。管倉庫的小夥子做資料清理，手一抖，把物料明細表裡的記錄刪了一大片，沒帶條件，整表清掉了一多半。這套系統是工廠的賬套底座，物料資料沒了，當天的收發貨全得停下。他第一反應是重新錄一遍，我們讓他先住手。

一、出事之後，第一件是別再動那臺機器

誤刪資料之後，最怕的就是"想著補救、結果把現場搞得更亂"。有人會馬上再操作一遍，有人會重啟資料庫，還有人直接拿備份覆蓋上去。這幾個動作都可能讓本來能救的資料變得救不回來。穩妥的做法是先停業務寫入，把現場凍住，再去看還有哪些手段可用。

那次我們讓客戶先停掉了系統入口，任何人不再往資料庫寫東西，然後連上去看這臺伺服器平時到底有沒有開日誌。

二、為什麼日誌能把刪掉的資料找回來

MySQL 這類資料庫，如果開啟了 binlog，所有寫操作——插入、更新、刪除——都會按順序記進日誌檔案，誰在什麼時候改了什麼，一條不落。這份日誌本來的用途是做資料同步和恢復，可誤刪的時候，它就成了唯一能還原現場的記錄。

關鍵是要找對位置。日誌裡每條操作都能定位到具體時間點，只要知道誤刪大概發生在什麼時刻，就能把日誌截到那一刻之前重放，把正確的資料補回來；刪除那一段跳過不執行，被刪的記錄就回來了。原理不復雜，難的是現場別被破壞、時間點別記錯。

三、一次誤刪的實際還原過程

那次我們的順序是這樣的：先確認誤刪的時間點，從客戶的操作記錄和資料庫日誌的時間戳對上；再把全量備份恢復到一臺隔離的機器上，回到誤刪前最近的一個備份點；然後從備份點開始，把 binlog 一條條重放到誤刪前一刻；最後把這臺機器上的正確資料，導回生產庫。

整個過程都在隔離環境裡做，不碰生產資料，萬一重放錯了也能推倒重來。折騰了大半天，刪掉的物料記錄基本都撈了回來，只有誤刪之後這半天裡新產生的幾條變動需要人工補錄。比起整表重錄，代價小得多。

四、比"能恢復"更重要的，是"用不著恢復"

事後覆盤，問題出在許可權上：一個日常操作崗，不該有整表刪除的許可權。我們把客戶的賬號許可權重新理了一遍，危險操作收緊，關鍵表加上操作留痕。摩傑斯做工廠 MES、ERP 十四年，這類"差點出大事"的場景見過不少，所以給系統配的預設策略裡，自動備份加 binlog 留存一直是標配，2012 年在崑山成立至今，蘇州、江蘇一帶的客戶資料都是這麼保的。

備份不是擺設，要能還原、做過演練才算數。崑山、蘇州一帶的工廠，資料出過問題、不確定還能不能救的，可以先找摩傑斯看一眼，別急著覆蓋。

總結：

資料誤刪，第一反應應該是停手，不是補救。現場凍住之後，如果平時開了 binlog、又有全量備份，大機率能把記錄撈回來，做法就是"恢復到備份點，再把日誌重放到誤刪前一刻"。但最好的狀態是壓根用不著恢復——許可權收緊、危險操作留痕、備份加日誌留存，這幾件事做在前面，手一抖的代價才不會那麼大。

相關閱讀：更多同類問題可以看《工廠 IT 服務總覽》；延伸閱讀《預設帶異地備份與還原演練》、《ERP 資料庫崩潰的完整覆盤》。