--single-transaction仅对innodb有效，因其依赖mvcc快照机制实现无锁一致性备份；myisam等非事务引擎不支持该机制，会退化为全局读锁，混合引擎需改用--lock-all-tables或分表处理。
--single-transaction 是 mysqldump 实现 InnoDB 表“不锁表、一致性备份”的核心参数。它不是万能开关，用错反而导致备份失效或阻塞业务。
为什么 --single-transaction 只对 InnoDB 有效
--single-transaction 依赖事务快照（START TRANSACTION WITH CONSISTENT SNAPSHOT）来获取数据一致性视图。MyISAM、Memory 等非事务引擎不支持该机制，此时 mysqldump 会自动退化为加全局读锁（FLUSH TABLES WITH READ LOCK），实际就锁表了。
- 若库中混用 InnoDB 和 MyISAM 表，整个备份过程仍会被阻塞
- 可通过
SELECT ENGINE, COUNT(*) FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'your_db' GROUP BY ENGINE;检查引擎分布 - 混合引擎场景下，必须搭配
--lock-tables或改用--lock-all-tables，但会失去“热备”意义
常见误用：和 --lock-tables 同时出现
--single-transaction 与 --lock-tables（或 --lock-all-tables）互斥。一旦同时指定，mysqldump 会直接报错或静默忽略 --single-transaction，并执行锁表逻辑。
- 错误写法：
mysqldump -uroot -p --single-transaction --lock-tables test > backup.sql - 正确做法：删掉
--lock-tables；如需导出触发器/事件等元数据，用--triggers --events --routines替代 - 验证是否生效：开启 MySQL general log，观察 dump 过程中是否有
FLUSH TABLES WITH READ LOCK出现
必须配合的参数才能真正“可用”
仅加 --single-transaction 不足以支撑一次可恢复的生产备份。它只管数据一致性，不管结构、权限、binlog 位点等关键信息。
-
--routines：导出存储过程和函数，否则恢复后逻辑缺失 -
--triggers：导出触发器，否则业务逻辑异常 -
--events：导出事件调度器，否则定时任务丢失 -
--master-data=2：在备份文件头部写入CHANGE MASTER TO语句，用于后续主从搭建或 binlog 增量恢复 -
--databases或-B：显式声明数据库名，确保CREATE DATABASE和USE语句被包含，避免恢复时找不到目标库
推荐完整命令：mysqldump -uroot -p --single-transaction --routines --triggers --events --master-data=2 --databases yoshin | gzip > yoshin-$(date +%F).sql.gz
容易被忽略的两个边界条件
--single-transaction 的一致性保障有前提，不是“绝对安全”。
- 备份期间禁止执行 DDL：如
ALTER TABLE、DROP TABLE、TRUNCATE TABLE、RENAME TABLE。这些操作会导致事务快照失效，dump 文件可能报错或数据不一致 - 不能跨事务保证所有表：如果某张 InnoDB 表在备份中途被其他长事务修改（尤其是未提交的写入），该表的快照可能滞后于其他表——虽然整体是“一致的”，但并非“某一精确时间点”的镜像
真正需要强时间点一致性的场景（比如审计、合规），应结合 --master-data=2 + binlog 位置，再配合 mysqlbinlog 做精确到秒的恢复，而不是只依赖 --single-transaction。
