必须停sql线程并精准定位误删前gtid或binlog位置才能回滚，因stop replica不暂停i/o线程，relay log可能已混入误操作后事件；需查show replica status确认执行位置，解析relay log找安全位点，再用change replication source重置起点。
能直接回滚到误删前状态，但必须停掉SQL线程、精准定位到误操作前的最后一个GTID或binlog position，不能靠“大概时间”估算。
为什么不能只用 STOP REPLICA 就开始导出？
延迟从库的 SQL_Delay 只控制SQL线程执行relay log的等待时长，不代表当前已执行到哪个位置。误删发生后，I/O线程仍在持续拉取新binlog，relay log里可能已经混入了误操作之后的事件。如果直接 STOP REPLICA 后就导出数据，很可能导出的是已被清空的状态。
- 必须先查
SHOW REPLICA STATUS\G，重点关注Relay_Master_Log_File和Exec_Master_Log_Pos—— 这才是SQL线程实际执行到主库binlog的位置 - 再结合主库的
SHOW MASTER STATUS和误删时间，反向推算出“误删前最后一个安全position” - 若开启GTID，优先用
Retrieved_Gtid_Set和Executed_Gtid_Set对比，找出未执行的GTID区间
CHANGE REPLICATION SOURCE TO ... RELAY_LOG_FILE/RELAY_LOG_POS 是关键一步
仅靠 STOP REPLICA 无法把SQL线程“倒回去”，MySQL不支持负向回放。真正回退到误删前，得手动重置SQL线程的执行起点——也就是指定 relay log 中某个已知安全的 RELAY_LOG_FILE 和 RELAY_LOG_POS（该位置必须早于误删事务的起始点）。
- 这个位置不能靠猜：需用
mysqlbinlog --base64-output=decode-rows -v解析从库的relay log，搜索DELETE FROM或TRUNCATE TABLE前最近的COMMIT事件 - 重置命令示例：
STOP REPLICA; CHANGE REPLICATION SOURCE TO RELAY_LOG_FILE='relay-bin.000012', RELAY_LOG_POS=123456789; START REPLICA UNTIL SQL_AFTER_GTIDS = '...'; - 注意：MySQL 8.0.23+ 才支持
START REPLICA UNTIL SQL_AFTER_GTIDS；旧版本只能用UNTIL RELAY_LOG_FILE/RELAY_LOG_POS，精度略低
导出数据前务必确认表结构未变更
延迟从库恢复的前提是：误删期间没有执行过影响表结构的DDL（如 ALTER TABLE ADD COLUMN）。一旦结构变化，即使数据内容恢复正确，应用层读取时也可能因字段错位、类型不匹配而报错或丢数据。
- 检查从库上该表的
CREATE TABLE语句，与误删前最后一次备份中的定义逐字比对 - 若存在DDL，不能直接导出
SELECT * INTO OUTFILE，必须用mysqldump --no-create-info+ 手动补全字段列表，避免列顺序错乱 - 特别警惕
innodb_file_per_table=OFF场景下，DROP TABLE后又重建同名表导致ibdata1中残留元数据冲突
最易被忽略的点：延迟从库的 relay_log_purge=ON 默认开启，它会自动清理已执行完的relay log。一旦你没及时介入，那些包含误删前完整数据的relay log文件可能已被轮转删除——所以发现误删后第一件事不是登录从库，而是立刻在从库上执行 SET GLOBAL relay_log_purge=OFF;，锁住现场。
