mysqldump默认对MyISAM用表级锁、InnoDB不启用事务快照，混合引擎必须用--lock-all-tables保证一致性，且需确保REPEATABLE READ隔离级别和ROW/MIXED binlog格式。
mysqldump 默认行为对 InnoDB 和 MyISAM 完全不同
默认不加任何参数时，mysqldump 对 MyISAM 表用表级锁（LOCK TABLES），对 InnoDB 表则尝试用 --single-transaction 实现一致性快照——但这个开关默认是关的，实际效果取决于你是否显式启用。
这意味着：没加参数直接跑 mysqldump -u root testdb，MyISAM 会阻塞写入，InnoDB 却可能产生不一致备份（比如跨事务的多表状态错位）。
- MyISAM 备份期间，所有
INSERT/UPDATE/DELETE被挂起，直到 dump 结束 - InnoDB 默认不开启事务快照，实际执行的是“边查边 dump”，遇到并发 DML 就可能漏数据或重复
- 混合引擎库（常见于老系统）必须按最弱环节设计策略：只要有一张 MyISAM 表，整个备份就无法靠
--single-transaction保证一致性
混合引擎库必须用 --lock-all-tables 而不是 --single-transaction
--single-transaction 只对 InnoDB 有效，遇到 MyISAM、MEMORY 或其他引擎会静默失效，并继续执行——但备份结果已不可信。官方文档明确说它“only works for InnoDB tables”。
正确做法是统一降级到全局锁：--lock-all-tables，它对所有引擎都生效，用 FLUSH TABLES WITH READ LOCK 锁住整个实例。
-
--lock-all-tables会阻塞所有写入，但能保证跨引擎一致性 - 不要混用
--single-transaction和--lock-all-tables：后者会覆盖前者，且 mysqldump 不报错 - 如果只读库允许短暂停写，这是混合引擎下唯一靠谱的选择
- 注意：
FLUSH TABLES WITH READ LOCK在主从复制中可能卡住 SQL 线程，需提前检查SHOW SLAVE STATUS
MyISAM 备份不能依赖 --single-transaction，但可考虑 --lock-tables
对纯 MyISAM 库，--single-transaction 完全无效，mysqldump 会退回到默认的 --lock-tables（每 dump 一张表锁一张）。这比全局锁轻量，但仍有风险。
--lock-tables 是默认行为，但它在 dump 过程中逐表加锁、解锁，表与表之间存在时间差——如果你有跨表关联逻辑（如订单+订单项），这种备份无法保证业务一致性。
- 纯 MyISAM 场景下，
--lock-tables是最小开销选择，适合低峰期小库 - 若需强一致性，仍得上
--lock-all-tables，哪怕只有两张 MyISAM 表 - 避免用
--skip-lock-tables：MyISAM 没 MVCC，跳过锁等于接受损坏备份 - 备份前确认
myisam_recover_options配置，坏表可能让 dump 直接中断并报错Got error: 126: Incorrect key file
真正影响备份可靠性的不是引擎，而是隔离级别和 binlog 设置
很多人盯着 InnoDB/MyISAM 区别，却忽略了更关键的底层条件：mysqldump --single-transaction 要求事务隔离级别为 REPEATABLE READ，且 binlog_format 必须是 ROW 或 MIXED（STATEMENT 模式下某些函数会导致快照失效）。
- 执行前务必检查：
SELECT @@tx_isolation, @@binlog_format; - 如果隔离级别是
READ-COMMITTED，--single-transaction仍能运行，但无法保证跨表一致性 - 备份时加上
--set-gtid-purged=OFF（GTID 环境下），否则可能因 GTID 位置不匹配导致恢复失败 - 生产环境建议始终加
--routines --triggers --events：存储过程、触发器这些对象不随表自动 dump，漏掉就丢逻辑
备份工具本身很成熟，问题几乎都出在“以为默认就安全”——尤其是混合引擎+未验证隔离级别+没关 GTID 自动推导这几个点叠在一起时，备份看起来成功了，恢复时才发现数据对不上。
