--single-transaction是mysqldump对InnoDB表实现无锁一致性备份的必要参数，通过SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ和START TRANSACTION WITH CONSISTENT SNAPSHOT创建快照，避免数据不一致和锁表；但遇MyISAM表、长事务或冲突参数会退化为全局读锁。
--single-transaction 不是“需要加”，而是在备份 InnoDB 表且业务持续写入时，必须加才能避免数据不一致或锁表。不加它，mysqldump 默认逐表导出，不同表可能取自不同时间点，备份结果根本不是某一时刻的快照——恢复后很可能出现外键断裂、状态错乱、金额对不上等线上事故。
不加 --single-transaction 会发生什么
默认行为是按表顺序执行 SELECT * FROM table1、SELECT * FROM table2……中间没有任何事务包裹。这意味着：
- 若
orders表导出在上午 10:00:00，order_items表导出在 10:00:03，而期间有用户刚下单并提交，就会导致备份里只有主表记录、没明细，或反之 - MyISAM 表会触发
FLUSH TABLES WITH READ LOCK，整个库写入阻塞，直到所有表导出完成（哪怕只有一张 MyISAM 表） - DDL 操作（如
ALTER TABLE）可能在导出中途发生，导致结构与数据不匹配，mysqldump甚至报错退出
--single-transaction 实际做了什么
它不是“开启一个事务然后慢慢查”，而是精确执行两步：
SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READSTART TRANSACTION WITH CONSISTENT SNAPSHOT
之后所有 SELECT 都基于这个快照读，不受后续写入影响。关键点在于：这个快照建立后，UNLOCK TABLES 立即执行，表锁释放，写操作完全不受影响。
注意：该机制完全依赖 InnoDB 的 MVCC，所以对 MyISAM、MEMORY 等引擎无效——遇到它们，mysqldump 会自动降级为全局读锁。
为什么加了还卡住写入
常见误判是“参数加了就万事大吉”，但实际卡顿往往源于以下真实原因：
- 库中存在任意一张 MyISAM 表：
SELECT table_name, engine FROM information_schema.tables WHERE table_schema = 'your_db'必须全为InnoDB - 备份开始前已有长事务未提交：
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(NOW() - trx_started) > 60查出后需人工KILL - 命令里混用了冲突参数：
--lock-tables、--lock-all-tables、--master-data=1（未搭配--single-transaction）会直接覆盖掉无锁逻辑 - MySQL 版本低于 5.6.5 却用了
--master-data=2：旧版本下该组合仍会隐式锁表
安全可用的最小命令模板
生产环境建议用这个组合，已验证兼容 MySQL 5.7+ 和 8.0：
mysqldump --single-transaction --routines --triggers --events --no-autocommit -u root -p mydb > mydb_$(date +%Y%m%d).sql
说明：
-
--routines和--triggers默认不导出，漏了会导致恢复后存储过程/触发器丢失 -
--no-autocommit防止导入时每行都 commit 一次，大幅加速恢复 - 绝对不要加
--skip-lock-tables—— 它不解决任何问题，反而干扰--single-transaction的内部逻辑
真正容易被忽略的是：即使参数全对、引擎全 InnoDB、没长事务，如果备份过程中有人执行 DROP TABLE 或 TRUNCATE，快照虽能读到旧数据，但 mysqldump 在导出表结构时会失败——一致性快照只保数据，不保 schema 可变性。
