--single-transaction能绕过FTWRL，因其执行START TRANSACTION WITH CONSISTENT SNAPSHOT，依托InnoDB MVCC生成快照，全程不加锁，但仅限纯InnoDB库、无长事务、参数不冲突；否则退化为FTWRL。
能大幅减少，但必须满足三个硬性条件：全库 InnoDB、无长事务、参数不冲突。否则 FTWRL 仍会卡住写入，业务超时风险极高。
为什么 --single-transaction 能绕过 FTWRL
它不执行 FLUSH TABLES WITH READ LOCK，而是在备份开始时执行 START TRANSACTION WITH CONSISTENT SNAPSHOT，依赖 InnoDB 的 MVCC 机制生成一致性快照。后续所有 SELECT 都从该快照读取，不加任何表级或行级写锁。
关键前提是：innodb_lock_wait_timeout 建议设为 120，且事务隔离级别必须是 REPEATABLE READ（mysqldump 会自动设置，但如果客户端显式改过，可能被覆盖）。
- 该机制只对 InnoDB 表生效；一旦存在 MyISAM、CSV、MEMORY 等非事务表，
--single-transaction自动失效，退化为 FTWRL - 备份进程会等待所有活跃事务结束才启动快照，若存在运行超 30 秒的未提交事务，
mysqldump将卡在Waiting for table flush - 不能与
--lock-all-tables或--lock-tables共用——后者会强制覆盖前者，直接触发全局锁
MySQL 8.0+ 推荐用 LOCK TABLES FOR BACKUP 替代
这是原生支持的轻量级替代方案，比 FTWRL 细粒度得多：LOCK TABLES FOR BACKUP 不阻塞 InnoDB 的读写，只拦 DDL（如 CREATE TABLE、DROP INDEX）和非事务表更新。
执行前先确认版本：SELECT VERSION();，低于 8.0 不支持。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 需搭配
LOCK BINLOG FOR BACKUP才能拿到一致性 binlog 位点，否则恢复时可能因位点漂移失败 - 它不会被长事务阻塞，等待时间通常为毫秒级；真正耗时的是后续文件拷贝，而非锁本身
- 仍需避开业务高峰期执行 DDL，否则
LOCK TABLES FOR BACKUP会等正在执行的 DDL 完成
Percona Server 或 AliSQL 用户优先启用 Backup Lock
如果你用的是 Percona Server（非 MySQL 社区版），XtraBackup 2.4+ 默认启用 LOCK TABLES FOR BACKUP 机制，无需额外参数，但需确认 SHOW VARIABLES LIKE 'version%' 输出含 Percona 字样。
- 它不刷新表、不驱逐缓冲池，只等正在执行的冲突操作自然结束，因此等待远短于 FTWRL
- 备份日志中应出现
Executing LOCK TABLES FOR BACKUP，而非FLUSH TABLES WITH READ LOCK - 若仍卡住，重点查是否有活跃的 MyISAM 表更新或未完成的 DDL —— 这才是真正在等的“罪魁”
最容易被忽略的三个实际约束
即使写了 --single-transaction，以下任一不满足，热备就变冷备：
- 库中混有 MyISAM 表（哪怕只是
mysql系统库里的help_topic） - 备份前存在未提交事务，且
innodb_history_list_length持续 > 10000（说明 undo 日志清理受阻） -
--master-data=2虽不阻塞 DML，但要求 binlog 必须开启，且备份过程中不能发生FLUSH LOGS或RESET MASTER
真正安全的线上备份，从来不是“选哪个参数”，而是先确认引擎分布、监控长事务、再决定是否把锁移到从库或延迟从库上执行——FTWRL 的毫秒级持锁，也可能因一个未提交的 ALTER TABLE 变成数分钟不可控等待。
