正休息的時候一個電話將我的睡意完全打散，“開發童鞋寫update SQL的時候忘了加where條件了”，相信每一個DBA同學聽到這個訊息的時候都有罵街的衝動吧。萬幸只是單表寫花了，而不是哪位大神在DB裡面drop table玩。雖然已經很久沒進行單表恢復了，但是還好步驟都印在腦海中，沒有出問題的就恢復完了。

　　言歸正傳，記錄一下單表恢復的步驟和關鍵點，提醒自己也提醒大家。

第一步：

　　找一臺效能比較高的伺服器作為還原機，從備份池中將最近的一次備份恢復到這臺還原機上。當然這個前提是你有備份，且備份是可用的。（什麼？ 你告訴我沒有做備份，那麼同學你可以洗洗睡了，準備享受自由的空氣吧。）

　　注意：這個時候不要啟動同步，務必保持不同步狀態。

　　ps：多說一嘴，對於DBA來說，備份是最重要的一個環節，不但要有，還要定期檢查備份是否是可用的，這是DBA的必要素質之一。

第二步：

　　聯絡那個犯錯的開發同學要錯誤的SQL語句和時間點，然後從主庫的binlog中找到這條SQL的執行點。具體操作舉例如下

### 使用mysqlbinlog將二進位制日誌轉化為明文SQL日誌
mysqlbinlog mysql-bin.000123 > /data1/000123.sql

### 使用linux的grep命令根據“key word”找到那個引發資料寫花的SQL所在的位置
cat 000123.sql |grep -C 10 'key word' --color

### 標紅色的是問題SQL，及這條SQL開始的時間點，及下一條SQL的開始時間點，這2個pos位置非常重要
# at 20393709
#131205 20:55:08 server id 18984603 end_log_pos 20393779   Query  thread_id=16296016  exec_time=0  error_code=0
SET TIMESTAMP=1386248108/*!*/;
BEGIN
/*!*/;
# at 20393779
#131205 20:55:08 server id 18984603 end_log_pos 20394211   Query  thread_id=16296016  exec_time=0  error_code=0
SET TIMESTAMP=1386248108/*!*/;
update table tablename set names='xxxx';
# at 20394211
#131205 20:55:08 server id 18984603 end_log_pos 20394238   Xid = 92465981
COMMIT/*!*/;
# at 20394238
#131205 20:55:10 server id 18984603 end_log_pos 20394308   Query  thread_id=16296017  exec_time=0  error_code=0
SET TIMESTAMP=1386248110/*!*/;
BEGIN

第三步：

　　根據第二步得到的pos位置，啟動同步關係，但是需要停止到問題SQL之前的pos位置上，具體使用如下命令

### pos位置等於問題SQL begin的pos位置
slave start until master_log_file='mysql-bin.000123',master_log_pos=20393709;

　　然後跳過這個問題SQL，將同步change到下一個pos位置上，具體使用如下命令

### pos位置等於問題SQL commit之後的pos位置
change master to master_log_file='mysql-bin.000123',master_log_pos=20394238;

　　從上面兩條命令我們看出，第二步得到的兩個pos位置很關鍵。

第四步：

　　在主庫上將寫花的表改名，其目的有二個，其一，停止對這個表的寫入（當然這對業務會有一定的影響，會出現一段時間內的寫入失敗報警，需要提前和業務部門聯絡好），其二，一旦恢復失敗，至少還有一個寫花的表存在，可以很快的恢復成我們恢復操作之前的狀態。

### 在主庫上執行
rename table tablename to tablename_bak；

　　然後在還原機上執行dump操作，執行這個操作的使用需要注意，如果表中有中文字元，一定記得需要新增--default-chararter-set引數

　　然後在還原機上執行dump操作，執行這個操作的使用需要注意，如果表中有中文字元，一定記得需要新增--default-chararter-set引數

mysqldump -uusername -ppassword -S/tmp/mysql.sock dbname tablename --opt> tablename.sql

　　最後將這個檔案傳輸到主庫伺服器上，完成最後的恢復操作

### 可以選擇登陸mysql之後
source tablename.sql；

### 也可以在cmd介面
mysql -uusername -ppassword -S/tmp/mysql.sock < tablename.sql

　　當然也可以不這麼麻煩，直接執行如下命令，但是個人習慣處於儲存歷史操作記錄和中間結果的需要，我都是按照以上步驟完成，這樣可以儲存一個隨時可以恢復的文字檔案，心理更踏實一點。

### 快速的方法可以按照如下操作，在還原機上的命令
mysql -uusername -ppassword -S /tmp/mysql.sock dbname tablename | mysql -uusername -ppassowrd -hhost -Pport

　　通過以上命令就可以直接完成dump並匯入的操作了，缺點就是不會有一份備份檔案生成。

第五步：

　　基本DBA的事情就沒有了，這時候就需要告訴開發同學恢復完畢，進行應用測試及資料正確性效驗了。如果一切都沒有問題之後，我們需要將剛才rename的表drop掉，整個恢復操作就算大功告成了。

drop table if exists tablename_bak；

　　資料庫恢復是每個DBA必備的技能，需要熟練掌握，希望度過這篇文章的同學們都可以輕車熟路的進行恢復操作。

　　ps：這個操作，最好一萬年都不要用一次就最好了。

以上就是MySQL單表恢復的步驟的詳細內容，更多關於mysql單表恢復的資料請關注我們其它相關文章！