MySQL binlog恢复需配合全量备份实现时间点恢复，先确认binlog启用及文件位置，再定位起始/结束位置，最后按“全备→过滤binlog→重放”顺序执行。
MySQL 从 binlog 恢复数据，核心是利用二进制日志（binlog）重放指定时间段或位置的 SQL 操作。它不能单独使用，必须配合全量备份（如 mysqldump 或物理备份）一起完成时间点恢复（PITR）。关键在于找准恢复起点（即备份对应的 binlog 位置）和终点（误操作前的位置）。
确认 binlog 是否启用并找到对应日志文件
binlog 默认不开启，需先检查配置：
- 执行 SHOW VARIABLES LIKE 'log_bin';，返回 ON 表示已启用
- 运行 SHOW MASTER STATUS; 查看当前正在写的 binlog 文件名和起始 position（如 mysql-bin.000012，154）
- 用 SHOW BINLOG EVENTS IN 'mysql-bin.000012' LIMIT 20; 快速浏览事件，确认日志内容是否完整
- binlog 文件通常在 /var/lib/mysql/ 下，注意权限和磁盘空间是否充足
定位恢复所需的 binlog 起始与结束位置
这是最易出错的环节。假设你有 3 月 10 日凌晨 2 点的全量备份，而误删发生在 3 月 10 日上午 9:30：
- 还原全量备份后，查该备份生成时刻对应的 binlog 位置：可从备份文件头部找 CHANGE MASTER TO 语句，或用 mysqlbinlog --base64-output=decode-rows -v mysql-bin.000012 | grep -A2 "end_log_pos" 结合时间筛选
- 用 mysqlbinlog --base64-output=decode-rows -v --start-datetime="2024-03-10 02:00:00" --stop-datetime="2024-03-10 09:29:59" mysql-bin.000012 mysql-bin.000013 导出安全区间内的 SQL
- 若知道具体 position，可用 --start-position=12345 --stop-position=67890 更精准控制
执行恢复：先还原全备，再重放 binlog
顺序不能颠倒，否则会重复写入或跳过数据：
- 停应用，确保无新写入；用 mysql -u root -p db_name 恢复全量备份
- 将筛选出的 binlog 转换为可执行 SQL：mysqlbinlog --base64-output=decode-rows -v --start-datetime="2024-03-10 02:00:00" --stop-datetime="2024-03-10 09:29:59" mysql-bin.000012 mysql-bin.000013 > incremental.sql
- 过滤掉误操作语句（如 DROP TABLE、DELETE FROM user WHERE id=100），可用 sed 或文本编辑器手动删减
- 导入增量 SQL：mysql -u root -p db_name
验证与注意事项
恢复完成后务必校验，避免“以为恢复了，其实没生效”：
- 检查表行数、关键字段值、自增 ID 是否连续；对比备份前后的业务数据快照
- binlog 格式需为 ROW 或 MIXED，STATEMENT 在某些函数或非确定性语句下可能无法精确恢复
- 如果开启了 GTID，恢复时要用 --skip-gtids 或按 GTID 集合精确指定，否则可能报错“GTID already exists”
- 生产环境建议定期测试恢复流程，光有 binlog 不等于能恢复——日志损坏、过期清理、权限不足都可能导致失败
