MySQL时间点恢复需确保binlog开启且格式为ROW或MIXED；起点须衔接全量备份的binlog position或GTID；用mysqlbinlog按位置或时间过滤后应用，并验证关键字段一致性。
确认 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 解析本身无回滚机制，一旦误执行，只能重来。
