--single-transaction可避免FTWRL锁，通过REPEATABLE READ事务+MVCC快照实现InnoDB无锁备份，但对MyISAM等非事务表仍会退化为全局读锁；Percona Server可用LOCK TABLES FOR BACKUP替代，MySQL 8.0+推荐CLONE PLUGIN。
别让 FLUSH TABLES WITH READ LOCK 把线上业务锁死——它不是必须的，尤其当你的库全是 InnoDB 时。
mysqldump 用 --single-transaction 就能绕过 FTWRL
默认不带参数跑 mysqldump，它会悄悄执行 FLUSH TABLES WITH READ LOCK，所有写入立刻排队挂起。但如果你的库只用 InnoDB（绝大多数现代业务都是），--single-transaction 是更优解：
- 它在备份开始前启动一个 REPEATABLE READ 事务，靠 MVCC 快照保证一致性，全程不加全局锁
- 业务 INSERT/UPDATE/DELETE/SELECT 全部照常运行，零感知
- 注意：该参数对 MyISAM、CSV 等非事务表无效；若库中混有这类表，仍会 fallback 到 FTWRL
- 示例命令：
mysqldump --single-transaction --all-databases > backup.sql
Percona XtraBackup 启用 LOCK TABLES FOR BACKUP 替代 FTWRL
如果你用的是 Percona Server 或 AliSQL（非官方 MySQL 社区版），直接启用 Backup Lock 就能大幅缩短锁持有时间：
-
LOCK TABLES FOR BACKUP只阻塞 MyISAM 写入和所有 DDL，InnoDB 的读写完全不受影响 -
LOCK BINLOG FOR BACKUP单独锁定 binlog 位点，避免长事务或大查询拖慢锁释放 - XtraBackup 2.4+ 默认启用该机制；确认是否生效，可查备份日志里是否出现
Executing LOCK TABLES FOR BACKUP而非FLUSH TABLES WITH READ LOCK - 若仍卡住，检查是否有活跃的 MyISAM 表更新或未完成的 DDL —— 这才是真正在等的“罪魁”
MySQL 8.0+ 直接用 CLONE PLUGIN 彻底跳过锁逻辑
原生方案最干净：不用改备份脚本，不依赖外部工具，也不碰 MDL 锁。
-
CLONE LOCAL DATA在本地克隆一份物理副本，底层走文件快照 + redo 应用，全程无全局锁 - 要求目标路径空闲、磁盘空间 ≥ 源数据大小 × 1.2（含 redo 日志）
- 克隆后可立即用
START SLAVE或SET GTID_PURGED接入复制，PITR 支持完整 - 注意：clone 不复制 mysql 系统库权限表（如
mysql.user），需单独导出补全
存储层快照是终极兜底，但别忽略那“毫秒级 FTWRL”
哪怕你用 LVM/ZFS/EBS 快照，第一步仍需执行 FLUSH TABLES WITH READ LOCK —— 它不是摆设，而是为确保内存脏页落盘、binlog 位点精确对齐。
- 这一步实际耗时通常
- 所以关键不是“有没有 FTWRL”，而是“它要等谁”：排查
SHOW PROCESSLIST中状态为Waiting for table flush的线程 - 云环境优先选 EBS 或 Ceph 快照；本地部署慎用 LVM（xfs_freeze 更稳）
