确认 binlog 是否启用且格式正确
MySQL 时间点恢复的前提是
binlog已开启，且格式为
ROW或
MIXED（
STATEMENT格式在复杂语句下可能无法精确还原）。检查方法：
SHOW VARIABLES LIKE 'log_bin'; SHOW VARIABLES LIKE 'binlog_format';
如果
log_bin值为
OFF，或
binlog_format是
STATEMENT且涉及函数、临时表、非确定性操作，则时间点恢复可能跳过关键变更或产生不一致。
log_bin必须为
ON，且
binlog_do_db/
binlog_ignore_db未意外过滤目标库
binlog_format = ROW最稳妥，能捕获每一行变更；
MIXED多数情况可用，但需留意降级为
STATEMENT的隐式切换 若使用 GTID，恢复时需用
--skip-gtids或严格按
gtid_set截断，否则可能报错
GTID_PURGED contains gtid that is not in binlog
定位恢复起点：从全量备份时间戳开始找 binlog 位置
不能直接从任意时间开始解析，必须衔接上一次
mysqldump或物理备份的
binlog position或
GTID。常见做法： 若备份命令含
--master-data=2，dump 文件开头有类似
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000012', MASTER_LOG_POS=198765;—— 这就是起点 若用
xtrabackup，查看
xtrabackup_binlog_info文件获取
filename和
position若只有备份时间（如
2024-06-15 14:23:00），用
mysqlbinlog --base64-output=DECODE-ROWS -v扫描对应时间段的 binlog，搜索
CREATE DATABASE、
INSERT INTO xxx VALUES等标志性事件辅助判断
注意：
mysqlbinlog --start-datetime不保证精确到秒级事务边界，建议优先用
--start-position+
--stop-position定位。
解析并过滤 binlog 到指定时间点
核心命令是
mysqlbinlog，但直接重放可能误伤其他库或引入冲突语句（如
DROP DATABASE、重复
CREATE TABLE）。安全做法是先过滤再应用：
mysqlbinlog \ --base64-output=DECODE-ROWS -v \ --database=myapp \ --start-position=198765 \ --stop-datetime="2024-06-15 15:30:00" \ /var/lib/mysql/mysql-bin.000012 | mysql -u root -p myapp
--database只过滤显式指定库的事件（对跨库操作无效，如
INSERT INTO otherdb.t SELECT * FROM myapp.t会被忽略） 若需更细粒度控制，加
--exclude-gtids或用
sed删除
DROP/
CREATE语句（但需人工核对，
ROW格式下 DDL 不在日志里）
--stop-datetime是“截止时间前最后一个已提交事务”，不是“包含该时刻所有语句”——若该秒内有多事务，可能漏掉部分 强烈建议先用
mysqlbinlog ... | head -n 100预览输出，确认起止位置和语句类型
恢复后验证数据一致性
时间点恢复不是魔法，容易因以下原因失败：
备份与 binlog 之间存在FLUSH LOGS或 binlog 切换，导致位置不连续（查
SHOW BINARY LOGS对比文件序号） 应用过程中发生主从延迟、
SET sql_log_bin=0跳过记录、或 binlog 被
PURGE清理 恢复目标库已有同名表，且
INSERT语句含自增主键，导致主键冲突或跳过插入
验证时不要只看行数，应抽样检查关键业务字段（如订单状态、余额更新时间），并运行
SELECT COUNT(*) FROM t WHERE updated_at > '2024-06-15 14:23:00' AND updated_at 确认覆盖范围。binlog 解析本身无回滚机制，一旦误执行，只能重来。
