最直接、兼容性最好的判断方式是查information_schema.processlist中state='waiting for global read lock'的线程；若返回非空，说明ftwrl已生效并造成阻塞。
查 information_schema.PROCESSLIST 中的等待线程
最直接、兼容性最好的判断方式，就是看有没有线程卡在 Waiting for global read lock 状态。FTWRL 一旦生效，后续所有试图获取 MDL（比如 DML、DDL）的线程都会停在这一步。
执行这句即可：
SELECT ID, USER, HOST, DB, COMMAND, TIME, STATE, INFO FROM information_schema.PROCESSLIST WHERE STATE = 'Waiting for global read lock';
如果返回结果非空，说明已有线程被阻塞——此时 FTWRL 极大概率已被持有（注意：不是“正在执行中”，而是“已生效并造成阻塞”）。常见误判点：
-
STATE是大小写敏感的，必须完全匹配'Waiting for global read lock'，不能漏空格或写成小写 - 该查询本身不触发锁，但若 FTWRL 已持有时，新连接可能连
information_schema都查不了（极少见，多见于极端资源耗尽） - 返回为空 ≠ 没有 FTWRL；有可能 FTWRL 刚执行完、还没来得及阻塞其他线程，或阻塞发生在元数据锁层面但尚未反映到 STATE 字段（需结合下一步）
检查 performance_schema.global_status 的 Global_read_lock
MySQL 8.0.26+ 新增了这个状态变量，值为 ON 表示 FTWRL 正在生效，OFF 表示未持有。这是唯一能“直接确认”的指标，但只适用于 8.0.26 及以上版本。
执行：
SELECT VARIABLE_VALUE FROM performance_schema.global_status WHERE VARIABLE_NAME = 'Global_read_lock';
注意事项：
- 5.7 和 8.0.25 及更早版本查不到这个变量，会返回空结果，别当成
OFF - 该变量仅反映当前是否持有锁，不体现谁持有的、持有了多久
- 它不会因为
UNLOCK TABLES执行失败而残留，MySQL 内部保证状态与实际一致
交叉验证：用 SHOW OPEN TABLES WHERE In_use > 0 辅助判断
FTWRL 在加锁前会强制关闭所有打开的表（flush 阶段），所以正常情况下，只要 FTWRL 持有中，SHOW OPEN TABLES WHERE In_use > 0 应该返回空——因为所有表都被强制释放了缓存，新请求又进不来。
但要注意这只是一个旁证：
- 若返回非空，基本可排除 FTWRL 持有（除非有极特殊并发竞争，概率极低）
- 若返回空，不能单独断定 FTWRL 正在运行；也可能是实例刚启动、没任何活跃表访问，或所有连接都空闲
- 真正有用的是“趋势对比”：比如你发现某时刻
SHOW OPEN TABLES WHERE In_use > 0突然变空，同时大量线程卡在Waiting for global read lock，那基本就是 FTWRL 上线了
区分 FTWRL 和 LOCK INSTANCE FOR BACKUP
MySQL 8.0 引入了更轻量的备份锁 LOCK INSTANCE FOR BACKUP，它不会导致 Waiting for global read lock，也不会置位 Global_read_lock，但也会阻塞某些操作（如 DROP DATABASE、SHUTDOWN）。
如果你查不到 FTWRL 线索，但业务仍异常卡顿，要额外检查：
SELECT * FROM performance_schema.metadata_locks WHERE LOCK_DURATION = 'INSTANCE';
若结果中有 LOCK_TYPE = 'BACKUP' 且 OWNER_THREAD_ID 对应某个活跃连接，说明是新备份锁在起作用，不是 FTWRL。
容易忽略的一点：很多监控脚本只盯 PROCESSLIST 和 Global_read_lock，却对 LOCK INSTANCE FOR BACKUP 完全无感，导致误判为“没锁”，实际业务已受限。
