Xtrabackup仅对InnoDB实现真正热备，MyISAM因无redo日志和崩溃恢复机制，必须加FLUSH TABLES WITH READ LOCK短暂锁表备份，属“准冷备”；全库零停机热备需确保无MyISAM表（含mysql系统库）。
因为Xtrabackup依赖InnoDB的崩溃恢复机制，而非SQL层事务快照
Xtrabackup不是靠启动一个长事务去读取数据，而是直接扫描.ibd文件页，并实时捕获redo log变化。这个过程完全绕过MySQL Server层，只和InnoDB存储引擎交互。它利用的是InnoDB自身启动时就有的crash recovery逻辑：先拷贝不一致的数据页，再用redo前滚、undo回滚，最终达成一致性——这整套机制只存在于InnoDB中，MyISAM没有redo、没有MVCC、也没有LSN（Log Sequence Number）概念。
MyISAM表在Xtrabackup里为什么仍要锁表？
当使用innobackupex（已弃用但仍有遗留脚本）或新版xtrabackup --backup搭配--tables包含MyISAM表时，工具会在InnoDB数据拷贝完成后，执行FLUSH TABLES WITH READ LOCK来保证MyISAM文件（.MYD/.MYI）的一致性。这不是“热备”，而是短暂全局只读——期间所有写操作阻塞。所以严格来说：xtrabackup本身只对InnoDB热备；MyISAM部分是“准冷备”，只是锁的时间极短（通常几秒），常被误称为“热备”。
为什么不能给MyISAM也加个类似redo的东西？
MyISAM设计上就不支持事务、崩溃安全或原子写入。它的数据文件是直接追加/覆盖的，没有WAL（Write-Ahead Logging）机制，也没有checkpoint、LSN或page-level校验。即使Xtrabackup强行复制.MYD和.MYI，也无法验证它们是否处于某个一致状态——比如一个INSERT刚写完.MYD但还没更新.MYI索引，备份就会拿到损坏的中间态。这不是工具能力问题，是存储引擎底层模型决定的。
实际部署中最容易被忽略的兼容点
很多团队误以为“开了innodb_file_per_table=ON就能全库热备”，却忘了检查mysql系统库里的表：比如mysql.user、mysql.plugin默认是MyISAM（尤其老版本MySQL 5.6/5.7）。这些表若没显式用--include或--databases纳入备份范围，或者没在恢复后手动mysql_upgrade，会导致权限丢失或启动失败。真正零停机的热备，必须确认全库无MyISAM业务表，且系统表已迁移或单独处理。
