MySQL Enterprise Backup对InnoDB支持真正热备，MyISAM仅温备；必须用backup-to-image生成.mbi文件保障原子性与校验；增量备份实为“InnoDB增量+MyISAM全量”；恢复前须停服并清空数据目录。
MySQL Enterprise Backup（MEB）能对 InnoDB 表真正热备，但 MyISAM 表只是温备 —— 这不是配置问题，是引擎限制，必须接受。
mysqlbackup --backup-to-image 是唯一推荐的热备入口
用 backup 或 backup-and-apply-log 生成一堆散文件（.ibd、.MYD、.frm 等），恢复时极易出错：路径错乱、MyISAM 文件缺失、校验无从谈起。混合引擎库必须走 backup-to-image，它会打包成单个 .mbi 文件，并内置 checksum 和引擎元数据。
-
--backup-image=/backup/full_$(date +%Y%m%d).mbi：目标路径必须不存在，重复使用会报Image file already exists -
--backup-dir=/tmp/meb_stage：这是临时工作目录，需保证有足够空间（至少等于 datadir 大小） -
--datadir=/www/server/data：必须和SELECT @@datadir;输出完全一致，且mysqlbackup进程对该路径有读权限 - 别漏
--with-binlog：否则备份里不含 binlog 位置，后续无法做时间点恢复（PITR）
--compress 和 --parallel 要配对用，否则压缩反而拖慢
MEB 默认不压缩，加 --compress 后实际启用 ZSTD 算法；但若不配 --compress-threads 或 --parallel，压缩会串行执行，I/O 瓶颈没释放，整体耗时可能比不压还长。
- 建议组合：
--compress --compress-threads=4 --parallel=4 - 压缩比实测在 3:1～6:1（取决于数据重复度），不是文档写的“最高 10:1”
- 不要对 SSD 主机盲目开高并发 ——
--parallel=8在 NVMe 上可能引发 I/O 饱和，反而延长锁 MyISAM 的时间 - 如果 MyISAM 表多且写入频繁，宁可降为
--parallel=2 --throttle=30缩短FLUSH TABLES WITH READ LOCK持锁窗口
MyISAM 温备那几秒，卡在哪你得提前知道
MEB 对 MyISAM 不是“全程无锁”，而是分阶段加锁：锁表 → 刷盘 → 拷文件 → 解锁。只要有一个慢查询正在往 MyISAM 表写，FLUSH TABLES WITH READ LOCK 就会 hang 住，整个备份卡死。
- 运行前务必查：
SHOW PROCESSLIST，过滤State含Locked、Writing to net或Sending data的线程 - 别信
--no-locking：跳过 MyISAM 锁 = 拷出损坏的.MYD，恢复后REPAIR TABLE都救不回来 - 高峰期慎用
--incremental：它对 MyISAM 仍是全量拷贝，且锁阶段一样存在 —— 增量 ≠ 更快，只是节省了 InnoDB 存储 - 备份用户只需
RELOAD、PROCESS、REPLICATION CLIENT，不需要FILE或SUPER（旧文档常误写）
恢复前清空 datadir 是硬性前提，不是建议
mysqlbackup --backup-image=file.mbi copy-back 不会自动清理目标目录。残留的 ib_logfile*、auto.cnf 或旧 .frm 文件会导致 MySQL 启动失败，或更糟 —— 启动成功但数据错乱。
- 必须手动执行：
systemctl stop mysqld && rm -rf /www/server/data/* - 别用
rm -rf /www/server/data/*后留着lost+found目录 —— MEB 会把它当数据子目录处理，报错Unknown engine type - 恢复后首次启动，InnoDB 会自动重做未刷盘的事务，这个过程不可跳过，也无需干预
最易被忽略的一点：.mbi 文件不是“备份完成就万事大吉”，它只保障了文件完整性，不包含 binlog 后续变更。如果你依赖 PITR，--with-binlog 备份后，必须确保 binlog 归档持续可用 —— 这部分不在 MEB 管控范围内。
