MyISAM表可直接拷贝.frm/.MYD/.MYI文件冷备，InnoDB因依赖共享表空间、redo log及事务状态，必须全量拷贝ibdata1、.ibd、ib_logfile*等且需停库。
备份时 MyISAM 表能直接拷文件，InnoDB 不行
MyISAM 表数据以独立文件形式存在：.frm（表结构）、.MYD（数据）、.MYI（索引），只要表没在写入，停掉 MySQL 或加 FLUSH TABLES WITH READ LOCK 后，直接复制这三个文件就能完成冷备份。但 InnoDB 所有表默认共用一个或多个共享表空间（ibdata1），或启用 innodb_file_per_table=ON 后每个表对应一个 .ibd 文件 —— 即便如此，.ibd 也不能单独拷贝恢复，因为它的数据页依赖内存中的事务状态和 ib_logfile（redo log）的一致性。
常见错误现象：
• 直接 cp test.ibd 到另一台机器再 ALTER TABLE ... IMPORT TABLESPACE 失败，报错 Tablespace is not encrypted but encryption flag is set 或 Invalid tablespace
• 忘记同步 ibdata1 和日志文件，导致导入后数据乱码或启动失败
- MyISAM 冷备只需确保无写入，文件级拷贝即可，适合小站快速迁移
- InnoDB 冷备必须停库 + 拷全量：包括
ibdata1、所有.ibd、ib_logfile*、mysql/系统库目录，缺一不可 - 生产环境严禁用文件拷贝代替逻辑备份或物理热备工具
mysqldump 备份时要不要加 --single-transaction？
mysqldump 默认对 MyISAM 表使用 LOCK TABLES，而对 InnoDB 表——如果你不加参数，它也会锁表；只有显式加上 --single-transaction，才会利用 InnoDB 的 MVCC 特性，在备份开始时启动一个一致性快照，全程不锁表（前提是没执行 DDL）。MyISAM 完全不支持这个参数，加了也无效，仍会锁全表。
性能影响：
• 对大 InnoDB 表，--single-transaction 可避免备份期间业务阻塞，但会延长事务生命周期，可能拖慢长查询或触发 Undo Log 膨胀
• MyISAM 备份期间写操作完全阻塞，读操作虽可并发，但若备份耗时久，用户会感知明显卡顿
- 备份 InnoDB 一定要加
--single-transaction（除非你接受锁表） - 备份混合引擎库时，该参数只对 InnoDB 生效；MyISAM 部分仍会被锁，建议拆开备份或改用
mysqlpump（MySQL 5.7+）分引擎处理 - 如果库中混有 MyISAM 表且无法改造，
--lock-all-tables比默认的--lock-tables更可控（统一锁全部表，避免部分表锁、部分表不锁带来的不一致）
崩溃后恢复，InnoDB 自动修复，MyISAM 得手动修
InnoDB 崩溃重启时，会自动重放 redo log 并回滚未提交事务（通过 undo log），整个过程无需人工干预。而 MyISAM 没有日志机制，崩溃后大概率出现 .MYI 索引损坏或 .MYD 数据截断，MySQL 启动时报错 Table 'xxx' is marked as crashed and should be repaired，必须运行 REPAIR TABLE xxx 或离线用 myisamchk 工具修复。
容易踩的坑：
• 在从库上看到 MyISAM 表报 crashed，直接 REPAIR TABLE 可能丢失最新写入（因主从延迟或 binlog 未同步）
• myisamchk --safe-recover 虽安全但极慢，千万级表可能跑数小时，期间表不可用
- MyISAM 的
REPAIR TABLE不是“一键修复”，它可能跳过坏块、丢数据，且不保证主键唯一性恢复 - InnoDB 的崩溃恢复时间取决于
innodb_log_file_size和最近一次 checkpoint 的位置，通常秒级完成 - 线上禁用 MyISAM，尤其在主从架构中——从库 repair 操作会中断 SQL 线程，造成主从延迟雪崩
物理备份工具选 xtrabackup 还是 mydumper？
Percona XtraBackup 是目前唯一成熟支持 InnoDB 热备份的开源工具，它能拷贝 .ibd + ibdata1 + 日志，并在备份结束时生成 xtrabackup_binlog_info 记录精确 binlog 位点，支持流式压缩和加密。但它完全不支持 MyISAM 热备——遇到 MyISAM 表时会自动降级为加全局读锁，等同于冷备。
mydumper 是逻辑并行导出工具，对两种引擎都适用，但本质仍是 SELECT INTO OUTFILE，不带事务一致性保障（除非配合 --trx-consistency-only + 全局锁）。它快、轻量，适合中小库快速迁移，但无法替代物理备份做秒级 RPO。
- 纯 InnoDB 库：首选
xtrabackup，支持增量、压缩、流式、prepare 后直接 rsync 恢复 - 含 MyISAM 表的旧系统：xtrabackup 会锁全库，此时不如用
mysqldump --all-databases --routines --events --triggers+ 定时 binlog 备份组合 - 别迷信 “mydumper 比 mysqldump 快就一定好”——它导出的 SQL 在恢复时无法跳过已存在表，也没有
--skip-triggers等精细控制，出错后重试成本高
