先說(shuō)一個(gè)我親眼看到的事故凌晨三點(diǎn)群里有人發(fā)消息說(shuō)誤執(zhí)行了DROP TABLE訂單表沒(méi)了。那一刻所有人的表情大概都一樣——不是驚訝而是“完了”的空白。MySQL里的DROP、TRUNCATE、DELETE這三個(gè)命令平時(shí)看著都叫“刪數(shù)據(jù)”但它們的底層行為、恢復(fù)能力、執(zhí)行代價(jià)完全不是一個(gè)量級(jí)。我做了十幾年MySQL相關(guān)的工作見(jiàn)過(guò)太多因?yàn)檫@三個(gè)詞用錯(cuò)而導(dǎo)致的線上事故也踩過(guò)不少坑。這篇文章想把它們的區(qū)別、適用場(chǎng)景、隱藏細(xì)節(jié)和恢復(fù)辦法一次說(shuō)清楚適合剛學(xué)會(huì)DELETE就去生產(chǎn)庫(kù)操作的新手也適合背了很多面試題卻還沒(méi)真刀真槍處理過(guò)事故的運(yùn)維和開(kāi)發(fā)。刪錯(cuò)一次數(shù)據(jù)的代價(jià)遠(yuǎn)超你看完這篇文章花的十分鐘。1. 先分清本質(zhì)DELETE、TRUNCATE、DROP到底刪了什么很多人的第一個(gè)誤區(qū)是把這三個(gè)命令看成“刪除程度不同”的三個(gè)檔位DELETE刪少一點(diǎn)TRUNCATE刪全部DROP刪得更徹底。這個(gè)理解方向沒(méi)錯(cuò)但遠(yuǎn)遠(yuǎn)不夠。它們?cè)贛ySQL內(nèi)部走的完全是不同的路徑。1.1 命令屬性DML和DDL之間隔著一道鴻溝在MySQL的官方分類(lèi)里DELETE屬于DML語(yǔ)句TRUNCATE和DROP屬于DDL語(yǔ)句。這個(gè)分類(lèi)不是用來(lái)應(yīng)付考試的概念而是實(shí)實(shí)在在決定了它們的運(yùn)行行為和恢復(fù)能力。DELETE是DML所以它可以被WHERE條件限制只刪除符合條件的行它支持事務(wù)在COMMIT之前可以ROLLBACK它逐條修改、逐條記錄所以能返回受影響的行數(shù)。這些都是DML的典型特征。TRUNCATE是DDL雖然官方文檔說(shuō)它“邏輯上等價(jià)于刪除所有行”但內(nèi)部實(shí)現(xiàn)根本不是逐行刪除而是直接重建表或者重新分配表空間。它不支持WHERE不能被回滾執(zhí)行完返回0 rows affected甚至需要的權(quán)限不是DELETE而是DROP權(quán)限。DROP更不用說(shuō)它是DDL里最重型的操作把整張表的結(jié)構(gòu)、索引、觸發(fā)器、外鍵約束和所有數(shù)據(jù)一起扔進(jìn)回收站嚴(yán)格說(shuō)是沒(méi)回收站。它也不可回滾同樣隱式提交。我建議你記住這個(gè)判斷標(biāo)準(zhǔn)只要一條命令執(zhí)行前需要先提交當(dāng)前事務(wù)執(zhí)行后也自動(dòng)提交這就是DDL如果它可以在事務(wù)里回滾這是DML。DELETE在START TRANSACTION里可以安全回滾TRUNCATE和DROP不行這就是那條鴻溝。1.2 事務(wù)、回滾和binlog誰(shuí)能救你一把我經(jīng)常在事故復(fù)盤(pán)里看到一個(gè)高頻問(wèn)題“為什么我的事務(wù)里執(zhí)行了TRUNCATEROLLBACK沒(méi)用”因?yàn)門(mén)RUNCATE和DROP都會(huì)觸發(fā)隱式提交。即便你寫(xiě)的是START TRANSACTION; TRUNCATE TABLE temp_table; ROLLBACK;MySQL在執(zhí)行TRUNCATE之前就把當(dāng)前事務(wù)提交了ROLLBACK根本沒(méi)東西可回滾。這個(gè)行為在MySQL 5.7、8.0等版本里都一樣屬于DDL的默認(rèn)規(guī)矩。DELETE不一樣。它在事務(wù)里刪除后可以通過(guò)ROLLBACK把自己刪掉的行全部恢復(fù)。就算你已經(jīng)COMMIT了只要binlog開(kāi)啟了ROW格式且記錄完整鏡像還有機(jī)會(huì)基于binlog做反向解析恢復(fù)。為什么呢因?yàn)镈ELETE在binlog_formatROW的情況下會(huì)把每一行的before image也就是刪除前的完整數(shù)據(jù)寫(xiě)進(jìn)binlog日志。像binlog2sql、myflash這類(lèi)工具能把這些before image反向生成INSERT語(yǔ)句做到一定程度的“后悔藥”。TRUNCATE和DROP就難辦了。它們屬于DDLbinlog里記錄的是語(yǔ)句本身而不是每一行的數(shù)據(jù)鏡像。沒(méi)有行級(jí)逆操作自然就不能靠同樣的工具閃回。這里有一個(gè)嚴(yán)肅的結(jié)論誤刪數(shù)據(jù)后能不能恢復(fù)不取決于你想不想而取決于操作類(lèi)型和你的備份體系。提示如果你管理的是生產(chǎn)庫(kù)binlog建議長(zhǎng)期開(kāi)啟binlog_formatROW和binlog_row_imageFULL。這會(huì)讓日志變大但換來(lái)的恢復(fù)能力非常值得。1.3 存儲(chǔ)空間回收?qǐng)?zhí)行完表空間縮水了嗎從磁盤(pán)空間的角度看三者差別最明顯。DELETE是逐行刪除InnoDB在物理存儲(chǔ)層面只是把相關(guān)行標(biāo)記為已刪除并把原來(lái)占用的數(shù)據(jù)頁(yè)標(biāo)記為可復(fù)用并不會(huì)主動(dòng)把空間還給操作系統(tǒng)。所以你常會(huì)看到一種情況刪了幾百萬(wàn)行數(shù)據(jù)表邏輯上小了很多但.ibd文件一點(diǎn)都沒(méi)變小。如果想真正回收空間得執(zhí)行OPTIMIZE TABLE或者ALTER TABLE ... ENGINEInnoDB這類(lèi)重建表的操作代價(jià)不低。TRUNCATE在默認(rèn)的獨(dú)立表空間配置下會(huì)直接重建一個(gè)新表把舊表空間整個(gè)釋放掉。最直觀的體現(xiàn)就是執(zhí)行前表文件可能占了10GB執(zhí)行后立刻變成幾MB甚至接近初始大小。這是它速度快的核心原因之一。DROP更徹底直接把表空間文件刪除包括相關(guān)的索引和約束也都一起清掉。所以如果你只是想讓某張磁盤(pán)占用很大的表變“瘦”用DELETE是不行的必須考慮TRUNCATE或?qū)ｉT(mén)的表重建操作。反過(guò)來(lái)如果你只是想清空少量測(cè)試數(shù)據(jù)也別為了釋放空間去TRUNCATE因?yàn)樽栽隽泻屯怄I行為都會(huì)變。1.4 自增計(jì)數(shù)器與外鍵約束兩個(gè)最容易被忽略的差異TRUNCATE會(huì)重置AUTO_INCREMENT計(jì)數(shù)器。假設(shè)訂單表當(dāng)前自增ID已經(jīng)到1000000你執(zhí)行DELETE清空所有行下一條新數(shù)據(jù)的ID還是1000001但執(zhí)行TRUNCATE后自增ID會(huì)回到1。很多業(yè)務(wù)不允許這種行為比如訂單號(hào)、流水號(hào)必須保持單調(diào)遞增這時(shí)候你就只能選DELETE。TRUNCATE還有一個(gè)限制如果這張表被其他表的外鍵引用直接執(zhí)行會(huì)報(bào)錯(cuò)錯(cuò)誤碼通常是ERROR 1701提示“Cannot truncate a table referenced in a foreign key constraint”。因?yàn)镸ySQL不知道該不該保留外鍵關(guān)系下的數(shù)據(jù)一致性。DROP作為父表時(shí)也會(huì)遇到類(lèi)似的約束不能直接刪除子表還引用的父表。正確的做法是先處理子表或者臨時(shí)關(guān)閉外鍵檢查但關(guān)閉外鍵檢查這種做法風(fēng)險(xiǎn)很高我一般不建議在核心業(yè)務(wù)庫(kù)上這樣操作。這些差異平時(shí)看著都是“冷知識(shí)”但真到出事故的時(shí)候每一條都可能成為決定性因素。2. 怎么選真實(shí)業(yè)務(wù)場(chǎng)景里的刪數(shù)據(jù)姿勢(shì)脫離場(chǎng)景談命令都是空的。下面這幾種業(yè)務(wù)場(chǎng)景基本覆蓋了我實(shí)際工作中遇到的絕大多數(shù)刪除需求。2.1 清理帶條件的業(yè)務(wù)數(shù)據(jù)DELETE是唯一正解只要你的需求是“刪掉一部分?jǐn)?shù)據(jù)”比如刪除三年前的日志、清理狀態(tài)為已取消的訂單、去掉重復(fù)注冊(cè)的臨時(shí)賬號(hào)那就只能選DELETE。典型寫(xiě)法DELETE FROM orders WHERE status canceled AND created_at 2023-01-01;這條語(yǔ)句會(huì)返回實(shí)際刪除的行數(shù)可以根據(jù)這個(gè)數(shù)字確認(rèn)影響范圍如果業(yè)務(wù)允許你甚至可以放在一個(gè)事務(wù)里先SELECT COUNT(*)確認(rèn)行數(shù)再執(zhí)行DELETE確認(rèn)無(wú)誤后COMMIT。但在生產(chǎn)環(huán)境我強(qiáng)烈不建議一條DELETE試圖把幾百萬(wàn)行一次清完。你可以按主鍵范圍分批刪除每次刪一小段間隔幾秒再刪下一批。這樣做的好處是單次事務(wù)不會(huì)積累大量undo日志鎖持有時(shí)間短binlog不會(huì)瞬間暴漲主從復(fù)制延遲也更可控。比如DELETE FROM orders WHERE id BETWEEN 1 AND 50000;然后再用腳本推進(jìn)范圍。慢是慢一點(diǎn)但不會(huì)把數(shù)據(jù)庫(kù)干趴下。這個(gè)道理就像搬家你可以一次性把所有東西塞進(jìn)卡車(chē)但半路爆胎的風(fēng)險(xiǎn)遠(yuǎn)高于分幾趟搬。2.2 清空一張表但要保留結(jié)構(gòu)TRUNCATE如果你想把表里的數(shù)據(jù)全部刪掉但表結(jié)構(gòu)、索引、字段定義、權(quán)限設(shè)置都還要留著而且能接受自增ID從1重新開(kāi)始那TRUNCATE是最合適的。我常用它的場(chǎng)景包括壓測(cè)前重置數(shù)據(jù)、臨時(shí)中間表的下一次寫(xiě)入準(zhǔn)備、開(kāi)發(fā)環(huán)境初始化配置表。寫(xiě)法很簡(jiǎn)單TRUNCATE TABLE temp_user_score;為什么它快因?yàn)樗恢鹦袆h而是直接把原來(lái)的表“扔了”再重新建一張空表。沒(méi)有逐行的undo日志也沒(méi)有逐行的binlog事件自然就快。但要注意TRUNCATE需要DROP權(quán)限不是DELETE權(quán)限。很多公司給業(yè)務(wù)賬號(hào)只開(kāi)了DELETE結(jié)果執(zhí)行TRUNCATE報(bào)權(quán)限不足這不是配置壞了是MySQL本來(lái)就這么要求的。執(zhí)行前最好確認(rèn)一下表是否被外鍵引用、是否有全文索引這兩個(gè)場(chǎng)景都可能讓TRUNCATE失敗。提示在早期版本里InnoDB表如果帶有全文索引執(zhí)行TRUNCATE也可能報(bào)錯(cuò)。遇到這種情況可以先刪除全文索引截?cái)嗪笤僦亟ɑ蛘吒挠肈ELETE。2.3 連結(jié)構(gòu)一起移除DROP是最后的手段DROP TABLE用來(lái)徹底下線一張不再使用的表。比如舊的日志表、臨時(shí)表、已經(jīng)遷移完成的廢棄表。正常流程應(yīng)該分兩步RENAME TABLE orders TO orders_bak_20250101;然后觀察一段時(shí)間確認(rèn)業(yè)務(wù)沒(méi)有任何依賴后再DROP TABLE orders_bak_20250101;RENAME的成本極低但能給你留一條后悔的退路。別一上來(lái)就直接DROP尤其在周五下午執(zhí)行那基本等于給周末“埋雷”。如果這張表還在被視圖、存儲(chǔ)過(guò)程、下游數(shù)據(jù)同步任務(wù)引用DROP之后它們不會(huì)馬上消失但會(huì)在運(yùn)行時(shí)報(bào)錯(cuò)。所以下線一張表之前務(wù)必把依賴關(guān)系梳理清楚。2.4 生產(chǎn)上的組合策略先備份、再降級(jí)、后清理我給自己定的規(guī)矩很簡(jiǎn)單沒(méi)有備份的刪除都是耍流氓。在生產(chǎn)庫(kù)上哪怕是清理一張臨時(shí)表我一般也先做一次快速備份。小表直接mysqldump大表可以用只讀從庫(kù)先確認(rèn)數(shù)據(jù)或者用云廠商的快照。刪除前記錄當(dāng)時(shí)的binlog文件名和位置萬(wàn)一出問(wèn)題知道從哪個(gè)點(diǎn)恢復(fù)。如果是核心交易表我更傾向于“降級(jí)刪除”先RENAME成備份表觀察一個(gè)完整的業(yè)務(wù)周期再?zèng)Q定是歸檔還是DROP。很多所謂“誤刪數(shù)據(jù)”其實(shí)如果當(dāng)初多做了這一步RENAME根本不會(huì)釀成事故。3. 執(zhí)行細(xì)節(jié)和踩坑實(shí)錄這一節(jié)講的是實(shí)際操作中容易忽略的細(xì)節(jié)。很多問(wèn)題不是命令本身寫(xiě)錯(cuò)而是對(duì)執(zhí)行環(huán)境、版本行為和副作用認(rèn)知不足。3.1 大表DELETE為什么越刪越慢曾經(jīng)有張三億行的日志表我想清掉兩年以前的舊數(shù)據(jù)直接執(zhí)行DELETE FROM access_log WHERE created_at 2022-01-01;結(jié)果跑了將近兩個(gè)小時(shí)還沒(méi)結(jié)束從庫(kù)延遲越拉越大undo日志差點(diǎn)撐爆磁盤(pán)。后來(lái)排查發(fā)現(xiàn)這個(gè)表在created_at上沒(méi)有合適的索引刪除條件實(shí)際上觸發(fā)了主鍵范圍的大掃描每一步都要回表確認(rèn)再加上單條事務(wù)里累積的undo和binlog巨大所有負(fù)面影響都疊加在一起。所以大表DELETE前一定要先檢查執(zhí)行計(jì)劃。你可以把條件換成SELECT用EXPLAIN看掃描行數(shù)EXPLAIN SELECT * FROM access_log WHERE created_at 2022-01-01;如果type是ALL或者掃描行數(shù)是千萬(wàn)級(jí)說(shuō)明索引沒(méi)選好先建索引或者調(diào)整條件改成走主鍵的范圍刪除。另外要關(guān)注有沒(méi)有長(zhǎng)事務(wù)卡住。DELETE是DML會(huì)持有行鎖在默認(rèn)隔離級(jí)別下還可能有間隙鎖。如果同一張表上有更新事務(wù)長(zhǎng)時(shí)間不提交你的DELETE很可能一直卡在鎖等待上狀態(tài)要么是Updating要么是Waiting for table metadata lock。這時(shí)去information_schema.innodb_trx里看看事務(wù)持續(xù)時(shí)間往往能找到元兇。3.2 TRUNCATE的版本差異和權(quán)限陷阱TRUNCATE的報(bào)錯(cuò)我在不同環(huán)境里見(jiàn)得太多了。最經(jīng)典的是外鍵引用和權(quán)限問(wèn)題。外鍵場(chǎng)景的報(bào)錯(cuò)信息是ERROR 1701 (42000): Cannot truncate a table referenced in a foreign key constraint解決辦法不是硬刪而是先處理子表或者在明確風(fēng)險(xiǎn)的情況下臨時(shí)關(guān)閉外鍵檢查執(zhí)行完再恢復(fù)。但關(guān)閉外鍵檢查之后孤兒數(shù)據(jù)問(wèn)題會(huì)造成更大的數(shù)據(jù)臟亂我建議只在測(cè)試環(huán)境這么干。權(quán)限場(chǎng)景的報(bào)錯(cuò)是ERROR 1142 (42000): DROP command denied to user app_user% for table temp_table很多人不理解為什么TRUNCATE還要DROP權(quán)限。因?yàn)镸ySQL從設(shè)計(jì)上就把TRUNCATE當(dāng)作表級(jí)重建操作而不是行級(jí)刪除操作。權(quán)限收緊不是壞事業(yè)務(wù)賬號(hào)不給DROP權(quán)限反而能在誤操作時(shí)擋一道。MySQL 5.7和8.0在原子DDL上也有差別。8.0引入了atomic DDLDDL執(zhí)行過(guò)程更可靠不像5.7時(shí)代可能因?yàn)橹型颈罎⒘粝掳霃垰埲北怼５⒁膺@并不能讓TRUNCATE和DROP變成可回滾操作別指望原子DDL能救誤刪。3.3 DROP的依賴鏈視圖、存儲(chǔ)過(guò)程和主外鍵DROP TABLE不只是刪一張表那么簡(jiǎn)單。如果這張表被視圖引用視圖定義還在但查詢的時(shí)候會(huì)報(bào)“表不存在”如果存儲(chǔ)過(guò)程或函數(shù)引用了它平時(shí)SHOW CREATE PROCEDURE看不出問(wèn)題一執(zhí)行就報(bào)錯(cuò)。這些依賴不會(huì)在你執(zhí)行DROP時(shí)自動(dòng)清理它們會(huì)像墻上的釘子一樣留在那里直到某次調(diào)用把你絆倒。主外鍵關(guān)系更要小心。如果A表被B表外鍵引用A就是父表B就是子表。直接DROP TABLE A會(huì)報(bào)錯(cuò)ERROR 3730 (HY000): Cannot drop table A referenced by a foreign key constraint必須先刪除子表或者取消外鍵約束再刪父表。我自己見(jiàn)過(guò)一個(gè)案例開(kāi)發(fā)直接SET FOREIGN_KEY_CHECKS0后刪了父表結(jié)果子表里留下一堆懸空外鍵數(shù)據(jù)之后每次查詢都要加各種LEFT JOIN去規(guī)避臟數(shù)據(jù)損失比當(dāng)初多刪一個(gè)表還大。所以我的建議是FOREIGN_KEY_CHECKS0只能作為最后的臨時(shí)手段而且要由DBA確認(rèn)風(fēng)險(xiǎn)后操作業(yè)務(wù)人員不應(yīng)該有這個(gè)權(quán)限。3.4 undo log、binlog和閃回工具數(shù)據(jù)恢復(fù)的真實(shí)玩法先說(shuō)明一個(gè)容易誤導(dǎo)的觀點(diǎn)DELETE能恢復(fù)TRUNCATE和DROP不能恢復(fù)。這句話只對(duì)了一半準(zhǔn)確說(shuō)是“有完整binlog和備份時(shí)三種操作都能一定程度恢復(fù)沒(méi)有binlog時(shí)DELETE比另外兩個(gè)稍微多一線機(jī)會(huì)?！盌ELETE在binlog_formatROW且binlog_row_imageFULL的前提下binlog里記錄了每一行的before image。誤刪后可以立刻停止應(yīng)用寫(xiě)入用binlog2sql這類(lèi)工具反向解析出INSERT語(yǔ)句把數(shù)據(jù)插回去。這個(gè)操作我做過(guò)不止一次成功后心里只有四個(gè)字謝天謝地。TRUNCATE和DROP則要走“備份binlog回放”的路線。比如最近一次全量備份在凌晨1點(diǎn)誤刪發(fā)生在上午10點(diǎn)那就在臨時(shí)實(shí)例上恢復(fù)凌晨1點(diǎn)的備份然后用mysqlbinlog回放從1點(diǎn)到10點(diǎn)之間的binlog回放到誤刪語(yǔ)句之前停車(chē)。邏輯上可行但操作復(fù)雜耗時(shí)長(zhǎng)而且前提是binlog還保留著、沒(méi)有被PURGE掉。所以真正的“恢復(fù)能力”不是靠某個(gè)命令而是靠你有沒(méi)有備份體系、binlog是否完整、恢復(fù)演練是否做過(guò)。生產(chǎn)環(huán)境永遠(yuǎn)要給自己留退路。4. 常見(jiàn)問(wèn)題排查與速查表最后這部分是實(shí)戰(zhàn)排查思路和速查表我盡量寫(xiě)得可以直接當(dāng)工作手冊(cè)用。4.1 DELETE變慢的排查鏈路先看狀態(tài)再分析執(zhí)行計(jì)劃最后看鎖和事務(wù)。第一步用SHOW PROCESSLIST或者查performance_schema.processlist找到正在執(zhí)行的DELETE看State字段。如果顯示Updating說(shuō)明正在物理刪除行如果顯示W(wǎng)aiting for table metadata lock說(shuō)明有一個(gè)事務(wù)或者一條DDL還握著這張表的元數(shù)據(jù)鎖你的DELETE在排隊(duì)。第二步把DELETE條件原封不動(dòng)改成一個(gè)SELECT用EXPLAIN看掃描行數(shù)和索引使用情況。發(fā)現(xiàn)全表掃描優(yōu)先建索引如果索引選擇性很差考慮改變刪除條件通過(guò)主鍵范圍刪。第三步查information_schema.innodb_trx找長(zhǎng)時(shí)間不提交事務(wù)。長(zhǎng)事務(wù)不僅會(huì)讓自己的undo暴漲還會(huì)讓別的刪除任務(wù)跟著遭殃。線上清理數(shù)據(jù)最好選在業(yè)務(wù)低峰期并且控制單批影響行數(shù)。我分享一個(gè)經(jīng)驗(yàn)寧可多寫(xiě)幾行腳本分批刪除也不要試圖一條SQL解決所有問(wèn)題。分批刪除雖然慢但可控、可觀察、可隨時(shí)停止。一次跑幾個(gè)小時(shí)的大事務(wù)聽(tīng)著高效實(shí)際上是在賭數(shù)據(jù)庫(kù)的極限。4.2 TRUNCATE失敗和DROP權(quán)限報(bào)錯(cuò)的常見(jiàn)原因這里整理一張我最常遇到的情況速查表報(bào)錯(cuò)或現(xiàn)象常見(jiàn)原因處理思路ERROR 1701表被外鍵引用先處理子表或臨時(shí)關(guān)閉外鍵檢查ERROR 1142用戶缺少DROP權(quán)限聯(lián)系DBA授權(quán)或改用其他方案執(zhí)行卡住有查詢持有MDL鎖找到阻塞會(huì)話并kill或等待其結(jié)束帶全文索引的表執(zhí)行報(bào)錯(cuò)InnoDB全文索引沖突先刪全文索引執(zhí)行后再重建在事務(wù)里執(zhí)行后無(wú)法回滾DDL隱式提交理解并接受不要指望回滾很多時(shí)候報(bào)錯(cuò)信息本身已經(jīng)把原因?qū)懙煤芮宄酥皇俏覀兲睕](méi)耐心看。我處理線上問(wèn)題的一個(gè)習(xí)慣是先把完整的報(bào)錯(cuò)原文復(fù)制下來(lái)再去查文檔而不是憑記憶瞎猜。4.3 DROP之后還有機(jī)會(huì)恢復(fù)嗎我的實(shí)操流程如果真發(fā)生DROP TABLE誤操作我的動(dòng)作順序是這樣的你可以直接抄第一時(shí)間停止應(yīng)用寫(xiě)入或者至少暫停所有相關(guān)表的寫(xiě)操作別讓binlog繼續(xù)被新數(shù)據(jù)覆蓋。馬上查看備份策略和binlog確認(rèn)最近一次全量備份是什么時(shí)候當(dāng)前binlog文件和位置是多少。找一臺(tái)臨時(shí)實(shí)例恢復(fù)最近的全量備份。全量備份結(jié)束的位置就是回放起點(diǎn)。用mysqlbinlog從備份結(jié)束點(diǎn)開(kāi)始回放到誤刪語(yǔ)句之前的位置停止。這樣臨時(shí)實(shí)例上就有了一張“誤刪前”的完整表。用mysqldump把這張表導(dǎo)出再導(dǎo)入到生產(chǎn)環(huán)境驗(yàn)證數(shù)據(jù)量、自增ID、關(guān)鍵行數(shù)據(jù)是否對(duì)得上。流程不復(fù)雜但每一步都可能踩坑。比如binlog已經(jīng)被清理了、備份是兩天前的、中間有大量DDL都會(huì)讓恢復(fù)失敗。所以判斷能不能恢復(fù)先看備份和binlog是否完整其余都是運(yùn)氣問(wèn)題。提示不要把恢復(fù)流程留到出事以后才第一次演練。我建議維護(hù)一個(gè)文檔每季度在測(cè)試環(huán)境完整跑一次“誤刪恢復(fù)”演練。真到事故那天你會(huì)發(fā)現(xiàn)這半小時(shí)的演練比任何運(yùn)維工具都值錢(qián)。4.4 速查表和我自己的經(jīng)驗(yàn)總結(jié)最后放一張適合貼在工位上的速查表對(duì)比項(xiàng)DELETETRUNCATEDROP類(lèi)型DMLDDLDDL支持WHERE是否否事務(wù)內(nèi)可回滾是否否受影響行數(shù)返回實(shí)際行數(shù)返回0返回0重置自增否是表沒(méi)了釋放表空間通常不釋放釋放完全釋放所需權(quán)限D(zhuǎn)ELETEDROPDROP觸發(fā)DELETE觸發(fā)器是否表沒(méi)了基于binlog單行恢復(fù)有機(jī)會(huì)不可不可主要風(fēng)險(xiǎn)慢、日志大、鎖自增重置、外鍵限制表結(jié)構(gòu)也沒(méi)了我做MySQL運(yùn)維這么久對(duì)刪除操作只有一個(gè)態(tài)度權(quán)限永遠(yuǎn)最小化刪除前永遠(yuǎn)先備份binlog永遠(yuǎn)保留足夠天數(shù)恢復(fù)演練永遠(yuǎn)不要省。DELETE、TRUNCATE、DROP三個(gè)詞看起來(lái)簡(jiǎn)單但每一條都代表對(duì)數(shù)據(jù)的一次取舍。哪怕你只是清一張開(kāi)發(fā)環(huán)境的臨時(shí)表也請(qǐng)花兩分鐘確認(rèn)手里有退路。很多事故不是命令寫(xiě)錯(cuò)而是寫(xiě)命令的人少問(wèn)了一句“如果刪錯(cuò)了我能不能反悔”