log_bin必须为on且binlog_format必须是row，否则无法精确还原被删行；需通过show variables确认配置生效，并检查binlog_row_image是否为full，再用mysqlbinlog解析write_rows事件提取快照，转为insert ignore语句导入并验证数据一致性。
log_bin 必须为 ON，且 binlog_format 必须是 ROW，否则无法精确还原被删的行——这是所有恢复操作的前提，不是可选项。
确认 binlog 是否开启且格式为 ROW
很多人卡在第一步：以为开了 binlog，其实只是配置了但没生效，或者格式仍是 STATEMENT。直接连上 MySQL 执行：
SHOW VARIABLES LIKE 'log_bin'; —— 返回 ON 才算真正启用SHOW VARIABLES LIKE 'binlog_format'; —— 必须是 ROW，MIXED 或 STATEMENT 会导致部分 DELETE 无法反向提取SHOW VARIABLES LIKE 'binlog_row_image'; —— 建议检查是否为 FULL（5.7 默认就是，但若被改过会影响恢复精度）
常见坑：
• SET GLOBAL log_bin = 'ON' 会报错 —— log_bin 是只读变量，必须改 my.cnf 并重启
• 配置里写成 log_bin = ON 或 log-bin=ON 都无效，正确写法是 log-bin=mysql-bin（注意是短横线，不是下划线）
• 没配 server-id 会导致 binlog 不生成（尤其在某些发行版或容器环境里）
用 mysqlbinlog 定位并提取删除前的原始数据
误删后别急着恢复，先从 binlog 里“捞”出被删行的快照。关键不是找 DELETE 语句，而是找它前面的 WRITE_ROWS 事件（ROW 格式下，每条 INSERT/UPDATE 都带完整行镜像）。
执行命令时带上必要参数：
• --base64-output=DECODE-ROWS：让二进制变更可读
• -v 或 -vv：显示详细字段值（-vv 还会显示类型信息）
• --start-datetime 和 --stop-datetime：缩小范围，避免解析几 GB 日志
• 示例：mysqlbinlog --base64-output=DECODE-ROWS -vv /var/lib/mysql/mysql-bin.000012 | grep -A 10 -B 5 "table_name.*WHERE.*id"
注意：
• mysqlbinlog 默认不校验 checksum，如果日志损坏可能静默跳过错误段
• 解析大文件时加 2>/dev/null 屏蔽警告，避免干扰 grep 匹配
• DELETE 事件本身不带数据，但紧邻的前一个 WRITE_ROWS 就是你要的“快照”
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
把 binlog 行事件转成 INSERT 语句再导入
直接拿 mysqlbinlog 输出重放不行 —— 它包含 BEGIN/COMMIT、其他表操作、甚至 DDL，混在一起会破坏数据一致性。稳妥做法是提取目标表的变更片段，手工或脚本转成 INSERT IGNORE。
手动提取要点：
• 找到 # at XXXXX 后紧跟的 ### INSERT INTO `db`.`table` 或 ### UPDATE `db`.`table` 块（不是 DELETE 块）
• 每个 ### SET 行对应一个字段，值已解码，复制出来拼成标准 INSERT
• 对主键/唯一键冲突敏感时，务必用 INSERT IGNORE 而非 REPLACE INTO，避免意外覆盖其他行
• 导入前先在测试库验证 SQL 是否语法正确、字段顺序匹配
容易忽略的细节：
• 时间字段（如 DATETIME）在 binlog 中可能带毫秒，而目标表定义不含毫秒，需截断或 CAST
• TINYINT(1) 类型常被当布尔存，在 INSERT 中写成 1/0 即可，别写 TRUE/FALSE
• 如果原表有自增主键，INSERT 时显式指定 ID，避免触发新自增值
恢复后验证不能只看行数
行数对了≠数据对了。尤其当误删发生在高并发写入期间，同一张表可能有其他人在同时 INSERT/UPDATE，单纯回放 binlog 片段会引入脏数据。
建议验证方式：
• 对比关键字段的校验和：CHECKSUM TABLE db.table（仅 InnoDB 支持），与备份时刻或日志分析前的值比对
• 抽样查几条被恢复记录的业务逻辑合理性（比如状态字段是否符合流转规则）
• 检查外键关联表是否出现孤立记录（例如订单恢复了，但用户表里对应 user_id 已不存在）
最隐蔽的风险点：
• TRUNCATE TABLE 或 DROP TABLE 不记 binlog 的行事件（只记 DDL），这种场景必须依赖全量备份 + 后续 binlog 回放，不能只靠单个 mysqlbinlog 文件
• DELETE 语句若带子查询或 JOIN，ROW 格式仍能记录被删行，但人工反推逻辑成本陡增，此时优先考虑闪回工具（如 mysqlbinlog-flashback）而非手写 SQL
