--single-transaction没生效的根本原因是库中存在MyISAM表或未显式禁用--lock-tables，导致mysqldump自动降级为FLUSH TABLES WITH READ LOCK全局锁；必须确保全库为InnoDB引擎并搭配--skip-lock-tables使用。
mysqldump --single-transaction 为什么没生效？
常见错误现象是加了 --single-transaction，但备份时业务写入依然卡住。根本原因不是参数写错，而是它被悄悄绕过了。
- 只要库中存在任意一张
MyISAM表（哪怕只有一张日志表），mysqldump就会自动放弃事务快照，退回到FLUSH TABLES WITH READ LOCK -
--lock-tables默认为 true，且优先级高于--single-transaction；如果没显式禁用，它会强制锁表 - 备份过程中执行了
ALTER TABLE或DROP TABLE，会触发隐式提交，直接中断当前快照事务，报错Cannot execute statement in a READ ONLY transaction
实操建议：先查引擎分布：SELECT table_name, engine FROM information_schema.tables WHERE table_schema = 'your_db';，确认全为 InnoDB；再确保命令中明确带上 --skip-lock-tables（等价于 --lock-tables=false，但语义更清晰）。
大表导出卡住、OOM 或 packet too large 怎么办？
--single-transaction 解决锁，但不解决内存和网络层问题。10G+ 表若不调参，mysqldump 可能缓存整表结果，导致客户端 OOM 或服务端报 Packets larger than max_allowed_packet。
- 必须搭配
--quick（或-q）：启用逐行流式读取，避免内存堆积 - 同步调大两端限制：
--max-allowed-packet=512M，并确认 MySQL 配置中max_allowed_packet≥ 同值 - 对超大库，可拆成单表备份并行跑：
mysqldump -u... --single-transaction --quick db_name table1 > t1.sql &，但注意跨表一致性需自行协调
MySQL 8.0+ 能用 LOCK TABLES FOR BACKUP 吗？
这是比 FLUSH TABLES WITH READ LOCK 更轻量的原生命令，毫秒级持锁，且不阻塞 InnoDB 表的 DML —— 但它不是万能替代，有硬性前提。
- 仅 MySQL 8.0.1 及以上支持，执行前务必验证：
SELECT VERSION(); - 它仍会阻塞所有 DDL（
CREATE INDEX、TRUNCATE等），不能在业务高峰期执行 - 不能单独用，得嵌入脚本：先
mysql -e "LOCK TABLES FOR BACKUP;"，再mysqldump，最后mysql -e "UNLOCK TABLES;" - 它不保证跨库一致性，多库备份时仍需额外控制顺序或使用
--single-transaction分库处理
混合引擎（InnoDB + MyISAM）怎么安全备份？
只要有一张 MyISAM 表，--single-transaction 就失效，全局锁无法避免。此时唯一可靠路径是转移风险位置，而非硬扛。
- 绝对不要在主库执行：锁表期间所有写入阻塞，DDL 堆积，半同步复制可能触发主库事务超时回滚
- 必须在延迟从库操作，且备份前先
STOP SLAVE，记录Exec_Master_Log_Pos和Relay_Master_Log_File，保证恢复后能精准续接主从 - 若连从库都不可停，考虑存储层快照（LVM/ZFS/EBS）：
FLUSH TABLES WITH READ LOCK→ 立即打快照 →UNLOCK TABLES，锁表时间压到亚秒级
真正容易被忽略的是：--single-transaction 的一致性窗口依赖长事务存活时间，如果备份耗时 2 小时，而业务里有个未提交事务卡了 1 小时 59 分，那这个事务的修改就不会出现在备份里——它不是“备份开始时刻”的快照，而是“事务启动时刻”的快照。
