恢复 binlog 前必须确认：①log_bin 已启用（show variables like 'log_bin' 返回 on）；②binlog_format 为 row；③存在误操作前的完整物理备份。
binlog 恢复前必须确认的三件事
MySQL 的 binlog 不是万能回滚开关，恢复失败往往源于前置条件没对齐。先确认：
• 服务器已启用 log_bin（执行 SHOW VARIABLES LIKE 'log_bin';，返回 ON 才有效）
• binlog_format 是 ROW（STATEMENT 格式下部分 DML 可能无法精确还原）
• 你有对应时间点或位置点前的完整物理备份（比如 mysqldump 或 xtrabackup 备份），否则只能恢复到 binlog 开始之后的数据
用 mysqlbinlog 提取指定范围的操作日志
直接解析 binlog 文件需要跳过头部、识别编码、过滤无关事件——mysqlbinlog 是唯一可靠工具。
• 查看起始位置和时间：运行 mysqlbinlog --base64-output=decode-rows -v /var/lib/mysql/mysql-bin.000002 | head -20，找到 # at 198 和 #240510 10:23:41 server id 1
• 截取误删前的操作：例如从位置 198 到 12345，执行 mysqlbinlog --start-position=198 --stop-position=12345 /var/lib/mysql/mysql-bin.000002 > restore.sql
• 时间范围更常用：用 --start-datetime="2024-05-10 10:20:00" 和 --stop-datetime="2024-05-10 10:23:41"，但注意时区需与 MySQL 服务端一致（查 SELECT @@time_zone;）
跳过误操作语句的两种安全方式
不能直接把整个 binlog 导入，否则会重放 DROP/DELETE。必须剔除问题事件：
• 方法一：用 --exclude-gtids（仅限 GTID 模式）配合 SET sql_log_bin=0 在目标库跳过特定事务
• 方法二（通用）：用 mysqlbinlog 输出 SQL 后人工编辑 —— 注意删掉 DROP TABLE、DELETE FROM user WHERE id=123 这类语句，但保留其前后的 BEGIN/COMMIT 结构，否则可能破坏事务一致性
• 关键细节：ROW 格式下的 DELETE 事件在输出里是 ### DELETE FROM `db`.`t1` 开头的注释块，实际执行的是反向的 INSERT，别误删整段
导入恢复 SQL 时最容易被忽略的权限和隔离问题
即使 SQL 文件内容正确，导入仍可能静默失败：
• 必须用有 REPLICATION CLIENT 权限的账号执行 mysqlbinlog，否则报错 ERROR 1227 (42501): Access denied
• 恢复时建议加 --force 参数（mysql --force -u root -p ），避免单条语句失败中断后续恢复<br>• 如果原库开启了 <code>read_only=ON，要临时关闭：SET GLOBAL read_only = OFF;，且确保当前用户有 SUPER 权限
• 最后务必验证：检查 SELECT COUNT(*) 和关键字段值，不要只看“Query OK”就认为成功
恢复真正难的不是命令怎么写，而是判断哪一段 binlog 该留、哪一段该切——尤其是跨多个 binlog 文件、涉及主从切换或 GTID 跳变时，位置点和时间点会错位。这时候必须结合 SHOW BINLOG EVENTS IN 'mysql-bin.000003' 逐文件核对。
