TRUNCATE无法用binlog直接还原，必须依赖全量备份+TRUNCATE前的ROW格式binlog DML重放，并在隔离环境验证后原子切换；需确认log_bin=ON、binlog_format=ROW、目标binlog文件未被purge。
TRUNCATE 无法用 binlog 直接还原，必须靠全量备份 + TRUNCATE 前的 binlog DML 重放，且整个过程必须在隔离环境完成。
确认 binlog_format 是 ROW 且未被 purge
TRUNCATE 是 DDL 操作，binlog 中只有一条语句记录，不带任何行数据。能恢复的前提是：你依赖的那些 INSERT/UPDATE/DELETE 事件确实被完整记下来了。
- 执行
SHOW VARIABLES LIKE 'binlog_format';—— 输出必须是ROW；STATEMENT或MIXED可直接放弃这条路 - 运行
SHOW VARIABLES LIKE 'log_bin';确认二进制日志已开启 - 用
SHOW MASTER LOGS;查看当前 binlog 文件列表，确认 TRUNCATE 发生前的文件（如mysql-bin.000023）还在，没被PURGE BINARY LOGS清掉 - 别指望
mysqlbinlog -v --base64-output=DECODE-ROWS扫出 TRUNCATE 日志下面有### SET @1=—— 它真没有
用 mysqlbinlog 精确截取 TRUNCATE 前的 DML 事件
目标不是解析 TRUNCATE，而是往前翻，在它之前把所有对该表的写入操作捞出来。时间窗口必须卡准，否则漏掉最后几条事务就前功尽弃。
- 先粗略定位 TRUNCATE 时间：
mysqlbinlog --base64-output=DECODE-ROWS /var/lib/mysql/mysql-bin.000023 | grep -A3 -B3 "TRUNCATE.*your_table" - 设
--start-datetime为最近一次全量备份完成时刻（比如mysqldump结束时间），--stop-datetime设为 TRUNCATE 执行前 5 秒（留安全余量） - 加
--database=db_name限定库，比grep table_name可靠得多——后者可能匹配字段名或注释 - 输出里必须保留
BEGIN和COMMIT，否则事务断裂，主键冲突、外键报错全是大概率事件
绝对不要在原库上执行恢复 SQL
哪怕只差一行 INSERT，也可能触发唯一键冲突或外键约束失败，把原库搞成只读甚至 crash。所有操作必须走隔离路径。
- 新建空库
recovery_db，导入原始全量备份（含表结构和初始数据） - 把截出的 binlog 片段用管道导入该库：
mysqlbinlog [options] mysql-bin.000023 | mysql -D recovery_db -u root -p - 验证
recovery_db.your_table数据是否符合预期（行数、关键字段值、自增 ID 连续性） - 确认无误后，再用
mysqldump -d recovery_db your_table > restored.sql导出，人工检查或替换后导入生产库
当 binlog 不可用时，xtrabackup 是更现实的选择
如果 binlog_format 不是 ROW，或者 TRUNCATE 前的 binlog 已被 purge，这条路就彻底堵死。这时候别硬刚 binlog，转头去翻 xtrabackup 备份才是正解。
- 进入已
--prepare好的备份目录，确认存在your_table.ibd和对应元数据文件（.frmfor 5.7，.cfg+.ibdfor 8.0） - 不能直接拷 ibd 文件到线上库 —— 表空间 ID 不匹配会导致启动失败，必须用
ALTER TABLE ... DISCARD TABLESPACE+IMPORT TABLESPACE流程 - 若连 xtrabackup 备份都没有，只剩底层文件抢救（如 ext4 上用
debugfs提取未覆写数据块），成功率极低，且要求磁盘未被大量写入
最容易被忽略的一点：TRUNCATE 后立即执行的任何新 INSERT，都会破坏原有自增 ID 序列和逻辑一致性。所以“恢复到 TRUNCATE 前”不是一句口号，而是必须精确到秒、并验证事务边界的实操动作。
