myisam 不支持基于 binlog 的精确时间点恢复，因其缺乏事务一致性保障和位置可重现性；虽 binlog 记录完整，但无崩溃安全提交、无原子回滚、无法保证数据状态一致，pitr 实际不可靠。
MyISAM 引擎本身不支持基于二进制日志（binlog）的精确时间点恢复（Point-in-Time Recovery），不是因为 binlog 不记录 MyISAM 操作，而是因为恢复过程缺乏事务一致性保障和位置可重现性。
MyISAM 的 binlog 记录是完整的，但不可靠用于 PITR
MyISAM 表的 DML（INSERT、UPDATE、DELETE）和 DDL（CREATE TABLE、ALTER TABLE）操作确实会写入 binlog（只要 log_bin = ON），且格式为 STATEMENT 或 ROW（MySQL 5.7+ 支持 ROW 格式写入 MyISAM，但有局限）。问题在于：
-
MyISAM不支持崩溃安全的事务提交，binlog中的事件顺序与磁盘上实际数据落盘顺序可能错位 -
binlog位置（如binlog.000012:426）在 MyISAM 场景下无法唯一对应一个数据一致的状态——同一位置前后几条语句可能部分成功、部分失败，且无回滚能力 - 执行
mysqlbinlog binlog.000012 | mysql -u root -p时，若中途出错（如主键冲突、磁盘满），MyISAM无法原子回退已执行的语句，导致数据半途损坏
SHOW MASTER STATUS 和 SHOW BINARY LOGS 对 MyISAM 无效
这两个命令本身能正常返回，但它们提供的信息对 MyISAM 的 PITR 没有实际指导意义：
-
SHOW MASTER STATUS返回当前binlog文件名和位置，但该位置不表示“所有 MyISAM 表都已持久化至此” -
SHOW BINARY LOGS列出文件列表，但 MyISAM 没有GTID或XA协调机制，无法跨表/跨库保证恢复边界的一致性 - 如果你用
mysqlbinlog --start-datetime="2026-05-08 14:30:00"截取一段日志重放，MyISAM 表很可能在重放中途处于中间状态（例如：某张表更新了，另一张关联表没跟上）
mysqlbinlog --binary-mode 是必须的，但救不了 MyISAM 的根本缺陷
当 binlog 含 \0 字符（常见于 BLOB 或某些字符集场景），不加 --binary-mode 会导致 mysql 客户端解析失败，报错类似：ERROR 1064 (42000) at line X: You have an error in your SQL syntax。但这只是传输层问题：
- 加上
--binary-mode能让mysql正确解析二进制内容，但不能解决 MyISAM 自身无 crash-safe commit 的问题 - 即便解析成功、执行成功，也无法验证结果是否与原始时间点完全一致——没有
START TRANSACTION/COMMIT边界，就没有“那一刻”的快照语义 - 真实生产中，MyISAM 的 PITR 唯一勉强可行的方式是：全库只有一张 MyISAM 表 + 所有操作串行 + 无并发写入 + 无 DDL —— 这种场景几乎不存在
InnoDB 是 PITR 的实际前提，不是可选项
MySQL 官方文档将 PITR 明确建立在 InnoDB 基础上，原因很实在：
-
InnoDB的binlog_position可与innodb_redo_log、checkpoint_lsn对齐，确保重放后数据页和索引页状态严格一致 - 备份工具（如 MySQL Enterprise Backup）从
backup_variables.txt提取的binlog_position=binlog.000012:426，其有效性依赖InnoDB的崩溃恢复能力；对 MyISAM，这个值只是“最后一条写入的语句位置”，而非“数据一致点” - 即使你强制用
mysqlbinlog --stop-position=426截断重放，MyISAM 仍可能因缓存未刷盘、索引未更新而呈现逻辑错误
InnoDB，要么改用逻辑备份（mysqldump --single-transaction）配合定期快照，而不能依赖 binlog 流式重放。
