MySQL Enterprise Backup对InnoDB支持真正热备，MyISAM仅温备；备份混合引擎库时自动对MyISAM执行FLUSH TABLES WITH READ LOCK分阶段加锁；必须用backup-to-image生成.mbi文件保障原子性与校验；增量备份对MyISAM无效，实为“InnoDB增量+MyISAM全量”；恢复前须停服并清空数据目录。
MySQL Enterprise Backup（MEB）能对 InnoDB 表真正热备，但 MyISAM 表只是温备 —— 这不是配置问题，是引擎限制，必须接受。
为什么 mysqlbackup 的“热备份”不等于全程无锁
很多人以为加了 --backup-and-apply-log 就万事大吉，其实 InnoDB 热备靠的是 MVCC 和 redo 日志快照，而 MyISAM 没有这些机制。MEB 备份混合引擎库时，会自动对所有 MyISAM 表执行 FLUSH TABLES WITH READ LOCK。这个锁不是从头持到尾，而是分阶段：先锁表 → 刷盘 → 拷文件 → 解锁。如果此时有个慢查询正往 MyISAM 表里写数据，FLUSH 就会卡住，整个备份 hang 住。
实操建议：
- 运行前用
SHOW PROCESSLIST查有没有 Command 是Query且 State 含Locked或Writing to net的线程 - 别用
--no-locking跳过 MyISAM 锁 —— 恢复后REPAIR TABLE都救不回来 - 低峰期加
--throttle=50降低 I/O 压力，缩短锁等待时间
backup-to-image 是混合引擎备份唯一靠谱的输出格式
用 mysqlbackup --backup-dir=/path backup 得到一堆散文件，InnoDB 的 .ibd 和 MyISAM 的 .MYD/.MYI 会被分别写进不同子目录。跨服务器传输或恢复时，顺序错乱、校验缺失，极易出错。
必须用 backup-to-image 打包成单个 .mbi 文件，原因很实际：
- InnoDB 的 redo 日志快照和 MyISAM 的文件快照必须原子打包，否则
apply-log阶段找不到对应 MyISAM 文件 -
.mbi内置 checksum，能验证 MyISAM 文件在传输中是否损坏（MyISAM 本身没页校验） - 恢复命令
mysqlbackup --backup-image=file.mbi copy-back会自动识别引擎类型，分发处理逻辑
增量备份对 MyISAM 实际无效，别被文档误导
MEB 的增量逻辑完全基于 InnoDB 的 LSN，MyISAM 没有 LSN 概念。当你执行 --incremental-base=history:last_full，它只比对 InnoDB 页变更 —— MyISAM 文件哪怕改了十次，增量备份也照旧跳过。
这意味着：
- 混合库做增量备份，实质是 “InnoDB 增量 + MyISAM 全量”
- 每次增量备份仍会完整拷贝所有 MyISAM 文件（截至上次全备时的状态）
- 不能靠增量备份来“追赶” MyISAM 的业务变更，得靠 binlog 回放或定期全备
最易被忽略的一点：恢复前必须停 MySQL，且目标数据目录必须为空 —— copy-back 不会清空旧文件，残留的 ib_logfile* 或 .frm 可能导致启动失败或数据错乱。
