truncate无法通过binlog直接恢复被删行数据，因其是ddl操作，仅记录事件本身而非行镜像；恢复前提是存在truncate前的全量备份及对应时段的row格式binlog，需定位并回放该时段内的insert/update事件至临时库后导出。
TRUNCATE 之后 Binlog 里根本没有 DELETE 记录
TRUNCATE 是 DDL 操作，MySQL 默认不会在 binlog 中记录逐行删除动作，而是只记一条 TRUNCATE TABLE 事件。这意味着你无法像恢复误删数据那样用 mysqlbinlog --base64-output=DECODE-ROWS -v 找到被删的行。除非你提前启用了 binlog_format = ROW 并且设置了 binlog_row_image = FULL，否则 binlog 里只有空壳事件，没有原始数据。
真正能恢复的前提是：表被 TRUNCATE 前，binlog 中已存在该表的完整写入历史（INSERT/UPDATE），且这些事件未被 purge。否则，binlog 本身就不含“被清空前的数据”。
- 检查当前 binlog 格式：
SHOW VARIABLES LIKE 'binlog_format';—— 必须是ROW - 确认是否记录了足够早的写入：用
mysqlbinlog扫描最早可用 binlog 文件，搜索INSERT INTO `your_table`或对应库表名 - TRUNCATE 本身在 ROW 格式下仍不记录行镜像，所以别指望从它那行日志里还原数据
用 mysqlbinlog 提取 TRUNCATE 前的 INSERT/UPDATE 语句
目标不是解析 TRUNCATE 那条日志，而是往前翻，在它之前找到所有对该表的有效变更。关键在于定位时间点或 position，然后导出 SQL。
- 先查 TRUNCATE 发生的大致时间：
SELECT * FROM mysql.general_log WHERE argument LIKE '%TRUNCATE%your_table%' ORDER BY event_time DESC LIMIT 1;（需开启 general_log） - 用
mysqlbinlog --start-datetime="2024-05-20 14:20:00" --stop-datetime="2024-05-20 14:25:00" /var/lib/mysql/binlog.000012截取窗口 - 加
--base64-output=DECODE-ROWS -v确保能看到 ROW 格式下的实际列值；若输出中出现### INSERT INTO `db`.`table`和### SET @1=... @2=...，说明数据可提取 - 过滤掉非目标表和 DDL：
mysqlbinlog ... | grep -E "(INSERT INTO \`your_db\`\.`your_table\`|@1=|@2=)" > restore.sql，再人工补全 INSERT 语句结构
直接回放 binlog 到临时库比“解析再导入”更可靠
手工拼 INSERT 容易漏字段、错类型、丢 NULL；而把 binlog 应用到一个隔离环境，能保留主键、自增、外键约束等上下文。前提是：你有 TRUNCATE 前某个一致的备份点（哪怕只是 mysqldump）。
- 找一个 TRUNCATE 前的全量备份（比如凌晨 3 点的 dump），导入到临时实例或新库
recovery_db - 用
mysqlbinlog --start-position=12345 --stop-position=67890 binlog.000012 | mysql -u root -P3307 recovery_db回放到那个备份之后、TRUNCATE 之前 - 验证
SELECT COUNT(*) FROM recovery_db.your_table;是否接近预期，再用mysqldump recovery_db your_table > restored_data.sql导出干净数据 - 注意：跳过 TRUNCATE 语句本身 —— 它会清空刚恢复的数据；可在 mysqlbinlog 输出中用
sed '/TRUNCATE/d'过滤，或用--exclude-gtids配合 GTID 跳过
为什么跳过 DROP/CREATE 或 ALTER 会影响恢复结果
如果 TRUNCATE 前后有表结构变更（如新增列、改类型），直接回放旧 binlog 可能因列数不匹配报错 Error 1644: Column count doesn't match value count。Binlog 的 ROW 事件是按当时表结构编码的，不是按当前结构解码的。
- 恢复前务必确认目标表结构与 binlog 写入时完全一致 —— 查
SHOW CREATE TABLE your_table在 TRUNCATE 时刻的定义（如有 slow log 或 DDL history 表可查） - 若结构已变，只能先建一张结构相同的临时表（
CREATE TABLE your_table_old AS SELECT * FROM your_table LIMIT 0;），再往它里面回放 -
mysqlbinlog默认按当前 server 字符集解析，若原写入用的是utf8mb4_0900_as_cs而现在是utf8mb4_general_ci，可能触发乱码或截断，需加--set-charset=utf8mb4
最常被忽略的一点：binlog 的 expire_logs_days 可能让关键日志早已被自动清理，TRUNCATE 前的那些 INSERT 很可能根本不在磁盘上了。恢复的第一步永远不是解析，而是确认日志还在不在。
