XtraBackup对MyISAM无法热备是因其无redo日志、LSN和崩溃恢复机制，数据与索引文件独立写入，必须用FLUSH TABLES WITH READ LOCK强制一致；xtrabackup跳过MyISAM，innobackupex则加锁备份；--no-lock对其无效；系统表如mysql.user（5.6/5.7默认MyISAM）若未显式包含将导致恢复失败。
XtraBackup 对 MyISAM 的限制不是实现疏漏，而是存储引擎模型决定的硬性边界——它根本没法在不锁表的前提下拿到一致状态。
MyISAM 为什么必须加 FLUSH TABLES WITH READ LOCK
MyISAM 没有 redo 日志、没有 LSN、没有崩溃恢复能力，数据文件（.MYD）和索引文件（.MYI）是独立写入的。一个 INSERT 可能先写完 .MYD，再更新 .MYI；备份若恰好卡在这中间，就会拿到索引缺失或错位的损坏副本。XtraBackup 唯一能做的，就是用全局读锁强制暂停所有写入，等所有 MyISAM 表完成刷盘后再拷贝文件——这不是“热”，是“温”。
xtrabackup 和 innobackupex 的行为差异
直接调用 xtrabackup 时，它压根不处理 MyISAM 表，连锁都不加，直接跳过；而 innobackupex（已弃用但仍有遗留脚本）会在 InnoDB 数据拷贝完成后，主动执行 FLUSH TABLES WITH READ LOCK，再拷贝 MyISAM 文件。这意味着：
- 如果你只用
xtrabackup --backup，且库中存在 MyISAM 表，它们不会出现在备份里 - 如果你用
innobackupex或新版xtrabackup --backup --tables显式包含 MyISAM 表，备份过程会短暂阻塞写入 -
--no-lock参数对 MyISAM 完全无效，加了也照样报错或导致不一致
最容易被忽略的系统表陷阱
MySQL 系统库 mysql 中的 user、plugin、proc 等表在 5.6/5.7 默认是 MyISAM。即使你业务表全是 InnoDB，只要没显式用 --include='mysql.*' 或 --databases=mysql 把它们纳入备份，恢复后就可能无法登录、权限失效、甚至 mysqld 启动失败。更麻烦的是，这些表在 mysqldump --all-databases 里会被自动包含，但在 XtraBackup 里默认被忽略——这种不一致极易在灾备演练时暴露。
真正零停机的热备，不是看工具标称“支持热备”，而是要确认：全库无 MyISAM 业务表 + 系统库表已迁移至 InnoDB（如通过 ALTER TABLE mysql.user ENGINE=InnoDB）+ 备份命令不含任何隐式依赖 MyISAM 的选项。
