混合引擎下必须用 --lock-all-tables，因 --single-transaction 对 myisam 无效，混用会导致备份不一致；--lock-all-tables 通过 flush tables with read lock 保证所有引擎跨表一致性，虽阻塞写入但最可靠。
混合引擎下 mysqldump 该用 --single-transaction 还是 --lock-all-tables？
不能混用，必须二选一，且选错会导致备份不一致或锁表范围失控。--single-transaction 对 MyISAM 表完全无效，它只对 InnoDB 启用 MVCC 快照；而 --lock-all-tables（即 -x）会全局加 FLUSH TABLES WITH READ LOCK，强制所有引擎（包括 InnoDB）进入只读状态，从而保证跨引擎一致性。
常见错误现象：
- 加了
--single-transaction但库中存在 MyISAM 表 → InnoDB 部分有快照，MyISAM 部分在备份过程中仍可被写入，最终 dump 文件里两部分数据时间点不一致 - 默认不加任何锁参数 → mysqldump 对 MyISAM 表用
LOCK TABLES锁单库内表，对 InnoDB 表也默认锁表（非事务快照），结果是锁行为不统一、耗时不可控、一致性无保障
实操建议：
- 若业务能接受短时停写（通常 ≤ 30 秒），直接用
--lock-all-tables，最简单可靠 - 若无法停写，且 MyISAM 表极少（如仅系统库里的
mysql.help_topic），可先ALTER TABLE mysql.help_topic ENGINE=InnoDB统一引擎，再启用--single-transaction - 严禁在混合引擎库中同时指定
--single-transaction和--lock-tables—— 它们互斥，mysqldump 会静默忽略后者并报 warning
mydumper 能否解决混合引擎锁等待问题？
可以，但需明确配置 --less-locking，否则它默认行为和 mysqldump 类似，仍会对 MyISAM 表长时间加锁。
--less-locking 的作用是：对 InnoDB 表仍用事务快照，对 MyISAM 表则改用更轻量的 FLUSH TABLES WITH READ LOCK + 快速拷结构 + 立即释放锁，把 MyISAM 锁持有时间压缩到毫秒级（仅用于获取表定义），大幅降低阻塞。
实操建议：
- 确认 mydumper 版本 ≥ 0.10.0（旧版
--less-locking有 bug，可能漏锁） - 搭配
--threads=4或更高（根据 CPU 核数），让 InnoDB 并行 dump，MyISAM 部分几乎不拖慢整体 - 避免使用
--no-schemas：MyISAM 表结构必须单独导出，否则恢复时建表失败
冷备份时直接复制 .ibd 和 .MYD 文件安全吗？
不安全。InnoDB 的 .ibd 和 MyISAM 的 .MYD 文件绝不能单独拷贝迁移或恢复。
原因很实在：
- InnoDB 的
.ibd文件依赖共享表空间ibdata1中的元数据、undo log 段、数据字典，还强依赖ib_logfile*中的 redo 日志状态 —— 缺一不可，否则ALTER TABLE ... IMPORT TABLESPACE必报Tablespace is not encrypted but encryption flag is set或Invalid tablespace - MyISAM 的
.MYD必须和同名的.frm（结构）、.MYI（索引）三者严格配对，且拷贝前必须确保表已FLUSH TABLES，否则.MYD可能含未刷盘的缓冲数据，恢复后查不到最新记录
实操建议：
- 真要冷备，请停库后整目录打包：
/var/lib/mysql/下全部内容（含ibdata1、ib_logfile*、所有.ibd、所有.MYD/.MYI/.frm、mysql/系统库） - 生产环境别碰冷备：恢复时必须同版本、同架构（x86_64 vs ARM）、同浮点单元，跨机器恢复失败率极高
有没有真正兼顾一致性与可用性的方案？
Percona XtraBackup 是目前唯一被验证可行的方案，但它对 MyISAM 的处理仍是“妥协式热备”——InnoDB 部分完全热备，MyISAM 部分仍需短暂全局锁。
XtraBackup 的实际流程是：
- 先对所有 InnoDB 表做无锁物理拷贝（利用崩溃恢复机制保证一致性）
- 再执行一次极短的
FLUSH TABLES WITH READ LOCK，仅用于拷 MyISAM 表的.frm/.MYD/.MYI，锁持续时间通常 - 最后释放锁，继续拷 binlog 位点等元信息
这意味着：只要 MyISAM 表数量不多、文件不大，整个备份过程对业务写入的影响可控制在秒级。比 mysqldump 的分钟级锁好得多，也比纯冷备灵活。
容易被忽略的关键点：
- XtraBackup 不支持 MySQL 8.0+ 的原生数据字典表（
mysql.ibd等），若用了新字典格式，必须降级或换用 mysqlbackup - 恢复时若含 MyISAM 表，务必用
xtrabackup --copy-back全量还原，不能只扔.ibd进去 —— 否则 InnoDB 字典和 MyISAM 文件系统视图会脱节
