MyISAM无法实现点对点精准恢复，根本原因是缺乏事务一致性语义：无START TRANSACTION/COMMIT边界、无崩溃安全提交、无原子回滚能力，导致binlog位置无法对应唯一一致的数据状态，即使binlog记录完整也难以保证重放结果与原始时间点一致。
MyISAM 表无法实现点对点精准恢复，根本原因不是 binlog 没记录，而是它压根没有事务一致性语义 —— 同一个 binlog 位置，无法对应唯一、可重现的数据状态。
binlog 确实写了，但位置（position）不表示“那一刻的一致快照”
MyISAM 的 INSERT/UPDATE/DELETE 会写入 binlog（只要 log_bin = ON），但这些事件之间没有 START TRANSACTION / COMMIT 边界。这意味着：
- 同一 binlog 文件中，
binlog.000012:426这个位置可能刚写完 A 表的 UPDATE，还没来得及写 B 表的关联 UPDATE；重放至此，A 表已变、B 表未动，数据逻辑断裂 - 崩溃发生时，binlog 中已刷盘的语句，和磁盘上 .MYD 文件实际落盘顺序可能错位 —— MySQL 不保证“binlog 写完，MyISAM 数据页也同步落盘”
-
SHOW MASTER STATUS返回的位置值，对 MyISAM 来说只是“最后一条语句写入 binlog 的偏移”，不是“所有表都持久化到该状态”的承诺
ROLLBACK 失效 + 崩溃不可恢复 = PITR 缺失原子基础
点对点恢复（PITR）依赖两个底层能力：事务可回滚、崩溃后能前滚到一致状态。MyISAM 全都不具备：
-
BEGIN和ROLLBACK在 MyISAM 表上被静默忽略，每条 DML 都是自动提交、不可逆的 - 没有 undo log，无法回退部分执行的语句；没有 crash-safe commit 流程，mysqld 异常退出后，无法判断哪些语句真正生效、哪些只写进 binlog 却没落地
- 用
mysqlbinlog --start-datetime="2026-09-30 15:20:00" | mysql -u root -p重放，极大概率卡在主键冲突或外键缺失 —— 因为中间状态本就不该存在
即使加 --binary-mode，也救不了引擎层缺陷
mysqlbinlog --binary-mode 只解决二进制内容解析问题（比如跳过 \0 字符导致的 SQL 语法错误），但它不提供任何事务协调能力：
- 加了
--binary-mode，mysql客户端能正确接收并执行语句，但执行结果是否与原始时间点一致？无法验证 - MyISAM 没有 GTID、没有 XA、不参与 binlog group commit，跨表操作天然不同步，binlog 里看似有序的语句，在重放时无法构成原子单元
- 真实生产中唯一“勉强可行”的 PITR 场景是：全库仅一张 MyISAM 表 + 所有写入串行 + 零 DDL + 零并发 —— 这种配置在 2026 年基本只存在于测试脚本里
真正要实现点对点恢复，必须把表引擎换成 InnoDB，并确认 autocommit = 1、binlog_format = ROW、且开启 gtid_mode = ON（如需跨实例一致性）。MyISAM 的设计目标从来就不是高可靠性恢复，它的优势在读密集、全文索引和简单修复 —— 把 PITR 当作需求时，引擎选型这一步就已经错了。
