mysqldump默认触发FTWRL导致业务卡住，因其强制全局只读锁阻塞所有写操作；根本解法是纯InnoDB库使用--single-transaction+--skip-lock-tables绕过FTWRL，确保无长事务、无MyISAM表且不混用冲突参数。
不能。FTWRL 本身是全局锁，不是降低等待的手段，而是造成等待的根源。
为什么 mysqldump 默认触发 FTWRL 就会卡住业务
不加任何参数运行 mysqldump，它会在备份开始时自动执行 FLUSH TABLES WITH READ LOCK（FTWRL）。这个命令会让整个实例进入只读状态：所有 INSERT、UPDATE、DELETE、CREATE TABLE 等写操作全部排队挂起，直到锁释放。
真正耗时的不是 FTWRL 本身（它执行很快），而是它在等：
- 正在执行的长查询（尤其是未加
LIMIT的UPDATE或DELETE） - 未完成的 DDL 操作（如
ALTER TABLE） - 处于
Waiting for table flush状态的线程（查SHOW PROCESSLIST可见）
--single-transaction 是绕过 FTWRL 的标准做法
对纯 InnoDB 库，--single-transaction 让 mysqldump 启动一个 REPEATABLE READ 事务，并用 MVCC 快照导出数据，全程不触发 FTWRL。
必须满足以下条件才真正生效：
- 库中所有表引擎都是
InnoDB（SELECT ENGINE, TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'your_db';） - 不能混用
--lock-all-tables或--lock-tables—— 这两个参数会强制覆盖--single-transaction - 没有运行超过 30 秒的活跃事务（查
INFORMATION_SCHEMA.INNODB_TRX中的trx_started） -
binlog_format为ROW或MIXED，且log_bin已开启（否则--master-data会失败）
MySQL 8.0+ 推荐用 LOCK TABLES FOR BACKUP 替代 FTWRL
这是比 FTWRL 细粒度得多的原生替代方案，但仅限 MySQL 8.0.22+ 且需确认支持：
- 执行
SELECT VERSION();确认版本 ≥ 8.0.22 - 手动测试：
mysql -e "LOCK TABLES FOR BACKUP;"，不报错即支持 - 它只阻塞 MyISAM 写入和所有 DDL，
InnoDB的读写完全不受影响 - 必须搭配
LOCK BINLOG FOR BACKUP才能拿到一致 binlog 位点，否则恢复可能出错
注意：该锁仍会被正在执行的 DDL 阻塞，所以避开 ALTER/CREATE 高峰期执行。
物理快照无法跳过 FTWRL，但能压缩其持有时长
哪怕你用 LVM/ZFS/EBS 快照，第一步仍是执行 FTWRL —— 它的作用是强制刷脏页、对齐 binlog 位点，确保快照一致性。
但它通常只持锁几毫秒，前提是：
- 没有慢查询或长事务卡在
Waiting for table flush -
innodb_max_dirty_pages_pct设置合理（建议 ≤ 75），避免刷盘压力过大 - 磁盘 I/O 能力充足（特别是 redo log 刷盘路径）
真正危险的是把 FTWRL 当成“可调优项”去折腾——它本不该出现在主库备份流程里。优先迁表到 InnoDB，再用 --single-transaction，才是最稳定、最易验证的路径。
