MySQL 8.0 PITR必须满足binlog开启且格式为ROW，否则不可行；时间戳恢复仅精确到秒，推荐用position或GTID精准定位，恢复前须停写并锁定。
MySQL 8.0 的 binlog 必须开启且格式为 ROW
不满足这个前提，基于时间戳的精确恢复（PITR）根本不可行。MySQL 8.0 默认 binlog_format 是 ROW，但很多生产环境会因兼容性原因改回 STATEMENT 或 MIXED——这会导致 mysqlbinlog --stop-datetime 恢复时跳过部分 DML，甚至恢复出错。
确认方式：SHOW VARIABLES LIKE 'binlog_format';
必须是 ROW；如果不是，需在 my.cnf 中显式设置：
binlog_format = ROW
注意：修改后需重启 MySQL，且所有已有 binlog 文件（非当前活跃日志）仍按旧格式记录，无法用于精确时间点解析。
用 mysqlbinlog 提取指定时间范围的事件时，–start-datetime 和 –stop-datetime 不是“秒级宽容”的
MySQL 的 binlog 时间戳来自服务器系统时间，且只精确到秒（即使你传入 2024-05-12 14:23:45.678，mysqlbinlog 也会向下取整到 2024-05-12 14:23:45）。这意味着同一秒内多条语句可能被整体包含或整体跳过，无法做到毫秒级精准截断。
实操建议：
- 先用
mysqlbinlog --base64-output=DECODE-ROWS -v /var/lib/mysql/binlog.000012 | grep -A2 -B2 "2024-05-12 14:23:45"手动定位目标事务起止位置 - 优先使用
--start-position和--stop-position替代时间参数，尤其是已知误操作前后的 position 值时 - 若必须用时间，备份前务必用
SELECT NOW();记录当前时间，并留出至少 2 秒缓冲窗口（例如想恢复到14:23:45，则设--stop-datetime="2024-05-12 14:23:43"，再人工补上关键事务）
恢复前必须停掉应用并确保无并发写入
binlog 是线性追加的日志，但 PITR 恢复依赖一个静态快照 + 一段确定的 binlog 区间。如果恢复过程中应用仍在写入，新产生的 binlog 会被混入恢复流程，轻则主从延迟加剧，重则导致数据二次损坏。
安全做法：
- 先执行
FLUSH TABLES WITH READ LOCK;（注意：该命令会阻塞所有写，且在 MySQL 8.0 中对某些 DDL 无效） - 立刻执行
SHOW MASTER STATUS;记下当前File和Position，作为“恢复终点”的参考基准 - 导出全量备份（如用
mysqldump --single-transaction），完成后立即UNLOCK TABLES; - 恢复时，先导入全量备份，再用
mysqlbinlog回放至目标时间点（不能跳过中间任何 binlog 文件）
mysqlbinlog 解析失败常见于 GTID 模式下的位置错位
MySQL 8.0 默认启用 GTID（gtid_mode=ON），此时 mysqlbinlog 输出中会包含 SET @@GLOBAL.GTID_PURGED 语句。若你用 --skip-gtids 参数忽略它，而目标实例的 gtid_executed 状态与源不一致，就会报错 Cannot add or update a child row: a foreign key constraint fails 或直接跳过事务。
稳妥方案：
- 恢复前先查目标实例的
SELECT @@global.gtid_executed; - 用
mysqlbinlog --include-gtids='xxx-xxx-xxx:1-100' /path/to/binlog.000012显式限定 GTID 范围，避免自动解析偏差 - 若从非 GTID 实例恢复到 GTID 实例，必须加
--skip-gtids --exclude-gtids='xxx-xxx-xxx:1-100'并手动清理gtid_purged
时间戳本身不携带事务边界信息，真正决定“恢复到哪一条语句”的，永远是 position、GTID 或你肉眼识别出的 # at XXXXX ——别迷信 --stop-datetime 的字面意思。
