Xtrabackup仅对InnoDB实现真正热备，因其依赖InnoDB的redo日志、LSN和崩溃恢复机制实现一致性；MyISAM无redo、无LSN、无page校验，备份时必须加FLUSH TABLES WITH READ LOCK，属“准冷备”。
热备份的本质不是“不锁表”，而是“能自洽恢复”
InnoDB 支持热备份，根本原因不是它“不加锁”，而是它的崩溃恢复机制（redo + undo + LSN）允许备份工具在数据页不一致的状态下拷贝文件，再靠日志前滚/回滚达成最终一致性。MyISAM 没有 redo log、没有 LSN、没有 page-level 校验，直接复制 .MYD/.MYI 时，哪怕只差一个字节写入未完成，备份出来的就是逻辑损坏的中间态——工具无法判断、也无法修复。
xtrabackup 对 InnoDB 是物理页扫描 + redo 捕获，对 MyISAM 只能 FLUSH TABLES WITH READ LOCK
执行 xtrabackup --backup 时：
- InnoDB 部分：跳过 MySQL Server 层，直接读取
.ibd文件页，并实时监听ib_logfile*的追加，全程无 SQL 层锁 - MyISAM 部分：必须等 InnoDB 拷完后，执行
FLUSH TABLES WITH READ LOCK，全局阻塞所有写入（包括 INSERT/UPDATE/DELETE/DDL），直到 .MYD/.MYI 文件拷贝完毕 - 如果命令里用了
--tables或--databases显式包含 MyISAM 表，xtrabackup 就会触发这个锁；没包含则直接跳过，导致备份集缺失这些表
mysqldump 的 --single-transaction 只对 InnoDB 生效
--single-transaction 的底层是启动一个 SERIALIZABLE 事务并获取一致性快照，这依赖 InnoDB 的 MVCC 和 undo log。MyISAM 完全无视该参数：
- 加了
--single-transaction备份含 MyISAM 表的库，MySQL 会默默忽略该参数，退回到默认的--lock-tables行为 - 混合引擎库若想全局一致，必须显式用
--lock-all-tables，否则备份中途 MyISAM 表可能被修改，而 InnoDB 表已拍下快照，产生跨引擎数据错位 - 老版本 MySQL（如 5.6）中
mysql.user等系统表默认是 MyISAM，容易被遗漏——恢复后权限丢失，但错误不报在备份阶段，而是在重启或首次登录时才暴露
云环境彻底弃用 MyISAM 不是技术保守，是运维不可控
阿里云、腾讯云、AWS RDS 等平台默认禁用 MyISAM，不只是因为热备问题：
- 主从同步依赖 binlog event 与存储引擎状态对齐，MyISAM 没有事务边界，
binlog_format=ROW下无法保证语句重放幂等 - 自动扩缩容时，MyISAM 的表级锁会让所有只读节点也排队等锁，ProxySQL 会把 MyISAM 查询强制路由到主库，打垮读写分离设计
- 崩溃后 MyISAM 表大概率进
crashed状态，云平台检测到就会标记实例异常、触发告警甚至自动隔离，而 InnoDB 重启即自动恢复
真正要落地热备，第一步不是选工具，是确认 SELECT COUNT(*) FROM information_schema.tables WHERE engine = 'MyISAM' 返回 0——包括 mysql 库里的所有表。
