应查INFORMATION_SCHEMA.PROCESSLIST中State为Locked/Sending data/Copying to tmp table且Time值大的线程，结合INNODB_TRX定位持锁长事务，而非直接KILL等待FTWRL的线程。
直接 kill 执行 FLUSH TABLES WITH READ LOCK 的线程没用——它卡住是因为别的线程正拿着表或事务锁不放，你杀它只是让锁等待链条更长。
怎么快速定位真正阻塞的线程？
别只盯着 SHOW PROCESSLIST 里状态为 Waiting for global read lock 的 dump 进程。重点看那些 State 是 Locked、Sending data 或 Copying to tmp table 且 Time 值特别大的线程：
- 这些往往是慢查询（比如隐式类型转换导致索引失效的 JOIN）正在持有表引用或 MDL 锁
- 也可能是长事务未提交，一直占着行锁 + MDL 写锁，让 FTWRL 拿不到全局读锁
- 如果库有 MyISAM 表，哪怕只有一张，FTWRL 就必须等它 flush 完，而 MyISAM 不支持事务，容易被大查询拖住
为什么 kill mysqldump 进程不能解决问题？
mysqldump 卡在 Waiting for global read lock 是结果，不是原因。它只是在等锁，真正“握着锁不放”的是其他线程：
- kill
mysqldump后，FTWRL 语句退出，但已持有的部分锁（如已关闭的表缓存）可能没完全清理干净 - 更危险的是：如果被 kill 的是正在执行
UPDATE的业务线程，它会触发回滚，而回滚过程本身要加行锁、写 undo、刷 redolog，反而加剧阻塞 - 正确做法是找到
Time最大、且Info显示慢 SQL 的线程（比如SELECT count(0) FROM customer_account ...），再 kill 它
如何避免下次再卡在 FLUSH TABLES WITH READ LOCK？
根本解法不是优化 kill 顺序，而是绕开 FTWRL：
- 全 InnoDB 库 → 改用
mysqldump --single-transaction，靠 MVCC 快照保证一致性，全程不触发 FTWRL - 混用引擎（含 MyISAM）→ 必须 FTWRL，那就得提前清理：停写、杀长事务、禁用慢查询入口，再执行
- 备份工具选
Percona XtraBackup→ 它对 InnoDB 走拷贝 ibdata + redo，对非 InnoDB 才用 FTWRL，且能自动跳过空表、压缩等待 - 绝对不要在业务高峰执行带 FTWRL 的操作；如果必须做，先
KILL掉所有Time > 60的连接，再执行
最常被忽略的一点：FTWRL 卡住时，UNLOCK TABLES 无效——因为锁根本没成功加上，命令都还没执行完。这时候唯一有效动作，是找到并终结那个让表“关不掉”的源头线程。
