--single-transaction 仅对 InnoDB 有效，通过 MVCC 实现一致性快照；对 MyISAM 等非事务表无效，需配合 --skip-lock-tables（前提无非事务表）并禁用 DDL，否则备份可能不一致或失败。
single-transaction 备份能保证一致性，但只对 InnoDB 有效
mysqldump --single-transaction 的核心作用是开启一个一致性快照（通过 START TRANSACTION WITH CONSISTENT SNAPSHOT），让整个备份过程看到的是事务开始那一刻的数据库状态。但它完全依赖 InnoDB 的 MVCC 机制：MyISAM、Memory 或其他非事务引擎的表不会被隔离，备份时仍可能被写入，导致数据不一致。
- 如果库中混用 MyISAM 表，
--single-transaction对它们无效，必须配合--lock-tables（会锁表）或改用--lock-all-tables（全局读锁，短暂阻塞写） - 即使全是 InnoDB，若事务中存在长查询或大事务未提交，
mysqldump启动的快照会等待这些事务结束，可能导致备份延迟甚至超时 -
autocommit=1是前提，否则手动开启的事务会影响快照行为
备份命令要加 --skip-lock-tables，否则 single-transaction 形同虚设
默认情况下，mysqldump 在启用 --single-transaction 时仍会为非事务表尝试加表级读锁（FLUSH TABLES WITH READ LOCK），这会导致短暂全局阻塞——和“不停机”目标冲突。
- 必须显式加上
--skip-lock-tables，才能跳过这一步 - 但前提是确认库中没有非事务引擎表，否则会报错或备份不一致
- 实际命令应类似：
mysqldump --single-transaction --skip-lock-tables -u root -p db_name > backup.sql - 若不确定引擎类型，先查：
SELECT table_name, engine FROM information_schema.tables WHERE table_schema = 'db_name';
备份期间 DDL 操作会破坏一致性
--single-transaction 只能隔离 DML（INSERT/UPDATE/DELETE），对 DDL（CREATE/DROP/ALTER）完全无防护。一旦备份过程中有表被删或结构变更，dump 文件可能包含部分旧结构 + 部分新数据，恢复时报错或丢数据。
- 最小化风险的方式：备份窗口内禁止任何 DDL，尤其避免
DROP TABLE和ALTER TABLE ... RENAME -
RENAME TABLE尤其危险——它在内部是原子操作，但mysqldump可能读到重命名前的表名，又读不到重命名后的数据 - 如果业务无法暂停 DDL，考虑用
mysqlpump（支持并行 + 更细粒度锁）或物理备份工具如Percona XtraBackup
备份文件体积大、恢复慢，不是所有场景都适合
--single-transaction 导出的是逻辑 SQL，全量文本。对于百 GB 级 InnoDB 库，dump 文件往往比实际 ibdata 文件还大（因含大量 INSERT 语句、重复字段名、无压缩）。
- 恢复时 MySQL 要逐条解析执行，速度远低于物理恢复（如 XtraBackup 的
innobackupex --copy-back） - 如果只是做容灾备份，且能接受分钟级停机，物理备份更稳更快
- 逻辑备份更适合跨版本迁移、筛选表导出、审计留痕等场景，别把它当万能解药
备份真正可靠的前提，不是参数多漂亮，而是清楚知道它在哪条边界上失效——比如 DDL、非事务表、长事务阻塞、磁盘空间不足导致 dump 中断，这些点没盯住，--single-transaction 再干净也没用。
