truncate表后数据不可事务回滚，但binlog_format=row且binlog未被purge时，可提取truncate前write_rows事件导出insert语句恢复；需验证log_bin=on、binlog_format=row、目标binlog文件存在，并用mysqlbinlog定位时间区间导出，再经binlog2sql等工具转换为可执行sql导入。
TRUNCATE 表后，数据不能靠事务回滚恢复，但只要 binlog_format = ROW 且对应 binlog 文件未被 purge，就能从 binlog 中提取出 truncate 前的全量 Write_rows 事件，重新 INSERT 回去——这是最可靠、最快捷的恢复路径。
确认 binlog 是否可用且满足恢复前提
恢复成败取决于三个硬性条件，缺一不可：
-
log_bin必须为ON（执行SHOW VARIABLES LIKE 'log_bin';验证） -
binlog_format必须为ROW（SHOW VARIABLES LIKE 'binlog_format';，MIXED或STATEMENT下 TRUNCATE 只记语句，无行数据） - 目标
mysql-bin.xxxxxx文件必须仍在磁盘上（SHOW MASTER LOGS;查看列表，确认未被PURGE BINARY LOGS清掉）
MySQL 8.0 默认启用 binlog，但若 DBA 手动关闭过或配置了自动清理策略，mysql-bin.000023 这类文件可能已消失。一旦缺失，这条路就走不通了。
用 mysqlbinlog 定位并导出 truncate 前的 Write_rows 事件
TRUNCATE 本身不产生 row event，你要找的是它“之前最后一次对该表的完整写入”——通常是某次批量 INSERT、LOAD DATA 或上次备份导入产生的 Write_rows 块。
- 先粗略定位 TRUNCATE 时间：
mysqlbinlog -v --base64-output=DECODE-ROWS /var/lib/mysql/mysql-bin.000023 | grep -A3 -B3 "TRUNCATE TABLE `your_table`" - 根据输出的时间戳，往前推 1–5 分钟，用
--start-datetime和--stop-datetime截取区间：mysqlbinlog --database=your_db --start-datetime="2026-05-31 16:22:00" --stop-datetime="2026-05-31 16:23:30" -v /var/lib/mysql/mysql-bin.000023 > before_truncate.sql - 导出内容全是注释格式的
### INSERT INTO `your_table`，需过滤掉BEGIN、COMMIT、SET @@SESSION.GTID_NEXT等非插入语句
注意：MySQL 8.0 的 GTID 模式会让输出更复杂，若启用了 GTID，建议加 --skip-gtids 参数避免导入失败。
导入前必须处理的兼容性细节
直接把 before_truncate.sql 丢进 mysql 会报错，因为原始 binlog 输出不是标准 SQL：
- 每条
### INSERT行是注释，真实值在下一行的### SET和### VALUES里，需转换；工具如binlog2sql（需 pip install）可自动完成，命令示例：binlog2sql -h127.0.0.1 -P3306 -uadmin -p'xxx' -d your_db -t your_table --start-file='mysql-bin.000023' --start-datetime='2026-05-31 16:22:00' --stop-datetime='2026-05-31 16:23:30' - 导入时务必用
INSERT IGNORE或REPLACE INTO，防止主键冲突（比如 truncate 后有人又 INSERT 了几行） - 如果表有自增主键，导入后记得
ALTER TABLE your_table AUTO_INCREMENT = N;（N 为最大已有 ID +1），否则后续 INSERT 可能报错
别忽略 innodb_flush_log_at_trx_commit 设置：若为 0 或 2，binlog 和 redo 日志可能不同步，导致你提取的事件不完整——这是线上环境最容易被忽略的隐性风险点。
