误删表之后的紧急处理顺序

误删表的第一动作不是找数据，是止住损失继续扩大。顺序一错，本来能完整恢复的数据，可能被后续写入搅得残缺不全。 ## 问：第一个小时做什么 按顺序做四件事。停写入：相关应用下线，必要时直接 systemctl stop mysqld，新数据进场会破坏现场。确认损失：哪张表、几点删的、DROP 还是 DELETE、谁执行的，这些决定恢复路径。盘点资产：最近一次备份在哪、binlog 是否连续、有没有延迟的从库。对齐预期：通知受影响方，把恢复方案和时间讲清楚，别硬扛着不说。每做一步记一条时间线，谁在几点做了什么，事后复盘全靠它。 ## 问：DROP 和 DELETE 恢复难度一样吗 不一样。DELETE 了行但表结构还在，binlog 是 ROW 格式时能从日志里把删掉的行原样补回；DROP TABLE 整张表消失，必须先恢复全量备份，再用 binlog 重放到删除之前。两种情况都依赖 binlog 完整，这也是生产库强制开 binlog 的理由。从库配了延迟复制的场景，在延迟窗口内把从库停住，旧数据就保住了，这正是延迟复制的价值所在。 ## 问：恢复为什么不能直接在生产上做 往生产库直接灌备份，中途任何一步出错都是二次事故。正确姿势是先起临时实例（另一台机器或容器都行），全量备份灌进去，用 mysqlbinlog 重放到误操作前一刻，核对行数和关键字段，确认无误再把表导回生产。 ## 问：什么备份都没有怎么办 逐条排查剩下的路：binlog 还在不在、从库延迟里有没有旧数据、存储层有没有快照。全都没有，立刻停止一切写入保护磁盘现场，联系专业数据恢复团队——业务继续跑，每一条新写入都在盖掉最后的机会。 ## 问：怎么防止再犯 权限收敛，日常账号不给 DROP；开启 sql_safe_updates，不带条件的 UPDATE 和 DELETE 直接被拒绝；恢复流程每季度演练一次，练过和没练过，出事时是两种速度。删除类操作走工单流程，两个人确认再执行，流程慢几分钟，换的是不用彻夜恢复。 事故预案平时看着多余，真出事那天，你会感谢那个提前把脚本写好、把流程练熟的人。