MySQL 的 binlog（Binary Log）是记录所有对数据库执行更改操作的日志，可用于数据恢复、主从复制等场景。要使用 binlog 恢复数据，核心在于：定位误操作发生的时间点或位置，然后跳过或回滚该操作，再重放其前后的合法日志。
binlog 的工作原理与启用前提
binlog 不记录 SELECT 查询，只记录 INSERT、UPDATE、DELETE、DDL 等写操作（格式取决于 binlog_format 设置：STATEMENT、ROW 或 MIXED）。它以事件（event）为单位顺序写入，每个事件包含时间戳、服务器ID、事件类型、SQL语句或行变更数据等信息。
要使用 binlog 恢复，必须满足以下条件：
MySQL 已开启 binlog（log_bin=ON，且配置了有效的 log_bin 路径） binlog_format 至少为 STATEMENT 或 ROW（推荐 ROW，更安全精准） 保留的 binlog 文件未被自动清理（检查 expire_logs_days 或 binlog_expire_logs_seconds） 有误操作前的完整备份（如 mysqldump 或物理备份），作为恢复起点恢复步骤：从备份 + binlog 回滚到指定时间点
典型流程是“全量备份 + 增量日志重放”，不直接“反向执行”binlog（MySQL 本身不提供逆向解析功能）。
先还原最近一次全量备份（例如用 mysqldump 导出的 SQL 文件导入，或 xtrabackup 恢复物理文件） 确认误操作发生的时间范围或 binlog 位置：可通过 MySQL 错误日志、应用日志、或 mysqlbinlog 工具查看事件时间戳和内容示例：mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.000012 | grep -A5 -B5 "DELETE FROM users WHERE id = 100" 提取误操作前的日志片段：用 mysqlbinlog 的 --start-datetime / --stop-datetime 或 --start-position / --stop-position 截取区间 将截取的日志导入 MySQL：mysqlbinlog --start-datetime="2024-05-20 10:00:00" --stop-datetime="2024-05-20 10:30:00" mysql-bin.000012 | mysql -u root -p
特殊情况处理：跳过单个错误事件或修复误删
若只是误删一条记录，且是 ROW 格式 binlog，可人工解析出反向 SQL（如把 DELETE_EVENT 转为 INSERT）；但更稳妥的做法是：
用 mysqlbinlog --base64-output=DECODE-ROWS -v 查看对应事件的原始行镜像（before_image/after_image） 手动构造 INSERT 语句还原该行（需注意字符集、自增、外键约束等） 若主库已启用了 GTID，可用 SET GLOBAL sql_slave_skip_counter = 1（仅临时跳过，需谨慎）或基于 GTID 的 RESET MASTER TO 方式跳过特定事务
