XtraBackup热备能力完全依赖InnoDB的redo log和LSN机制，MyISAM因无崩溃恢复能力，备份时被静默忽略，需用innobackupex加全局读锁处理；混合引擎库须降级安装percona-xtrabackup-24并检查mysql系统库中MyISAM表。
MyISAM 本身没有崩溃恢复机制，XtraBackup 无法绕过这点
XtraBackup 的热备能力完全依赖 InnoDB 的 redo log 和 LSN（Log Sequence Number）——它边拷贝 .ibd 文件页，边实时捕获 redo log 变化，最后靠 InnoDB 自身的 crash recovery 逻辑前滚+回滚达成一致性。MyISAM 没有 redo log、没有 LSN、没有 page-level 校验、也不支持原子写入，FLUSH TABLES WITH READ LOCK 是它唯一能提供文件一致性的手段。
xtrabackup 命令默认跳过 MyISAM 文件，不加锁也不报错
直接运行 xtrabackup --backup 时，工具只扫描并复制以下内容：
-
ibdata1、.ibd文件 -
redo log（ib_logfile*） - 部分元数据（如
backup-my.cnf）
它完全忽略 .frm、.MYD、.MYI —— 即使你库里有 mysql.user 这类默认 MyISAM 表，也不会被包含。更危险的是：不报错、不提示、不跳过整个备份，只是静默遗漏。恢复后执行 mysql_upgrade 或重启 MySQL 时，大概率报错 Table 'mysql.user' doesn't exist 或启动失败。
混合引擎库必须用 innobackupex，但注意版本兼容性
Percona 在 XtraBackup 8.0+ 中已彻底移除 innobackupex；而它才是唯一能安全处理 MyISAM 的封装脚本——它会在备份开始时自动执行 FLUSH TABLES WITH READ LOCK，等所有 MyISAM 表刷盘并锁住后才拷贝文件，结束后释放锁。
关键实操点：
- MySQL 5.7 / 8.0 且含 MyISAM 表 → 必须降级安装
percona-xtrabackup-24（CentOS：yum install percona-xtrabackup-24；Debian：apt install percona-xtrabackup-24） - 确认命令存在：
which innobackupex，若返回空，说明装的是 8.0+ 版本，得卸载重装 2.4 -
--databases不规避锁：哪怕只备份一个库，只要其中有一张 MyISAM 表，innobackupex仍会对整个实例加全局读锁
真正零停机的前提是全库无 MyISAM，包括 mysql 系统库
很多团队查完业务库全是 InnoDB 就以为万事大吉，却漏了 mysql.plugin、mysql.servers、mysql.general_log（如果启用）这些默认 MyISAM 表。它们在老版本 MySQL（5.6/5.7）中普遍存在，即使你用 xtrabackup 备份成功，恢复后也会因权限表缺失导致连接拒绝或功能异常。
检查命令：SELECT table_schema,table_name,engine FROM information_schema.tables WHERE table_schema='mysql' AND engine='MyISAM';
修复路径只有两条：
- 显式迁移系统表：
ALTER TABLE mysql.user ENGINE=InnoDB;（需先关闭skip-grant-tables，且 MySQL 5.7.29+ 才支持） - 或接受短暂只读，在备份阶段用
innobackupex兜底
最常被忽略的不是语法或参数，而是“mysql 库里还有 MyISAM 表”这个事实本身——它让所谓“热备”在最后一刻变成故障源。
