truncate表无法直接回滚，恢复仅依赖row格式binlog（未被purge）或xtrabackup等物理备份；否则需底层数据页抢救，成功率低。必须先验证binlog_format=row、log_bin=on且相关binlog文件未被purge，再从前序write_rows事件还原数据，或通过导入prepared ibd文件恢复。
TRUNCATE 表无法回滚，恢复只取决于你有没有保留下来的 binlog（且必须是 ROW 格式）或物理备份；没有这两样，就只能从磁盘底层抢救数据页——成功率低、耗时长、需要停库。
确认 binlog 是否能用
别跳过这步，90% 的人直接冲去解析 binlog，结果发现格式是 STATEMENT，白忙一场。
-
SHOW VARIABLES LIKE 'binlog_format'必须返回ROW；MIXED或STATEMENT没戏，因为 TRUNCATE 本身不记录行数据，只记一条空事件 -
SHOW VARIABLES LIKE 'log_bin'必须为ON，否则连日志都没开 -
SHOW MASTER LOGS查看当前 binlog 文件列表，确认 TRUNCATE 发生前的文件（比如mysql-bin.000023）还在——被PURGE BINARY LOGS清掉就彻底没了 - 用
mysqlbinlog -v --base64-output=DECODE-ROWS /path/to/mysql-bin.000023 | grep -A5 -B5 "TRUNCATE.*your_table"定位时间点，再往前查：TRUNCATE 日志下面不会出现### SET @1=这类行镜像，那是 INSERT/UPDATE 才有的
从 binlog 提取写入事件还原数据
目标不是解析 TRUNCATE 那条日志，而是找到它之前最后一次对该表的批量写入（比如全量导入或定时同步），从中提取 Write_rows 事件块。
- 用
--start-datetime和--stop-datetime截取 TRUNCATE 前 5–10 分钟的 binlog 片段，加-v --base64-output=DECODE-ROWS确保看到字段值 - 过滤时慎用
grep "INSERT INTO `db`.`table`"：手工拼 SQL 极易漏NULL、错类型、丢自增列，尤其遇到ENUM、JSON或带默认值的字段 - 真正可靠的做法是：把截出的 binlog 片段应用到一个干净的 MySQL 实例（版本必须一致），再用
mysqldump导出该表——这样能保留主键、外键、字符集、默认值等完整上下文
用 xtrabackup 物理备份恢复 ibd 文件
这是 binlog 不可用时最常用、成功率最高的路径，但要求你有近期的全备，且已执行过 xtrabackup --prepare。
- 进入准备好的备份目录，确认存在目标表的
your_table.ibd和对应元数据文件（MySQL 5.7 是your_table.frm，8.0 是mysql.ibd中的字典信息） - 不能直接拷
.ibd回原库：InnoDB 启动时会校验 space_id，不匹配会拒绝加载；必须用ALTER TABLE your_table DISCARD TABLESPACE+IMPORT TABLESPACE流程 - 导入前务必关闭
innodb_file_per_table = OFF的情况——此时数据在ibdata1里，没法单独抽表，得整库恢复
底层数据页抢救（无备份也无 binlog 时的最后手段）
本质是扫描磁盘原始块，靠页头校验和 frm 文件结构反推数据，成功率取决于 TRUNCATE 后是否发生写入覆盖。
- 立即停止所有写入：包括应用写 DB、日志轮转、临时文件生成，越早停，恢复概率越高
- 工具如
ibd2sql或undrop-for-innodb需要你提供完整的.frm文件（表结构）和原始数据文件（ibdata1或mysql.ibd） - 输出的 SQL 往往含重复记录、主键冲突、乱码字段（因特征匹配误判），必须人工清洗后才能导入，不能直接跑
最容易被忽略的一点：恢复出来的数据即使能导入，也不等于业务可用——自增 ID 可能错乱、外键约束可能失效、时间戳可能失真。验证时别只 count 行数，得抽样比对关键字段和关联逻辑。
