mysql 5.7 无 locked_connects 指标，属常见误称；应关注 innodb_row_lock_current_waits（当前行锁等待数）、innodb_row_lock_time_avg（平均等待耗时）等真实状态变量定位锁争用。
Locked_connects 不是 MySQL 5.7 的监控指标，它根本不存在于任何官方文档、系统变量或状态变量中。你查不到这个值，也用它判断不了“锁溢出”——因为 MySQL 没有“锁连接数”这一概念，更不存在基于连接数的锁溢出机制。
为什么Locked_connects查不到？
MySQL 5.7 的状态变量（SHOW STATUS）和系统变量（SHOW VARIABLES）里，没有任何一项叫 Locked_connects。常见混淆来源可能是：
- 把
Threads_connected（当前连接数）和Threads_running（当前活跃线程数）误记为“锁连接” - 把
Table_locks_waited（表级锁等待次数）简写错成类似名字 - 把第三方监控工具自定义的 metric 名称当成 MySQL 原生指标
执行 SHOW STATUS LIKE '%lock%'; 或 SHOW STATUS LIKE 'Thread%'; 都不会返回 Locked_connects。
真正该看的锁相关状态变量有哪些？
判断锁争用是否严重，应关注这些真实存在的、带累计计数的状态变量：
-
Innodb_row_lock_current_waits：当前正在等待行锁的事务数（瞬时值，>0 表示有阻塞） -
Innodb_row_lock_time_avg：平均每次行锁等待耗时（单位毫秒，持续 > 50ms 需警惕） -
Innodb_row_lock_waits：自启动以来发生的行锁等待总次数（突增说明锁竞争加剧） -
Table_locks_waited：表级锁（MyISAM 或显式LOCK TABLES）的等待次数（InnoDB 场景下通常为 0）
注意：Innodb_row_lock_current_waits 是唯一能反映“此刻有没有人卡住”的实时指标；其他都是累计值，需结合时间窗口对比趋势。
如果看到大量线程状态为Locked，实际是什么问题？
在 SHOW PROCESSLIST 中看到 State = 'Locked'，不代表“锁溢出”，而是表示该线程正被其他事务持有的锁（通常是元数据锁 MDL 或表锁）阻塞，典型场景包括：
- 一个长事务未提交，持有了
MDL_SHARED_READ锁，导致后续ALTER TABLE或DROP TABLE卡在Locked - 显式执行了
LOCK TABLES t1 WRITE但没UNLOCK TABLES - DDL 正在等待获取
MDL_EXCLUSIVE，而前面有未结束的 SELECT（尤其在REPEATABLE READ隔离级别下）
此时应查 sys.schema_table_lock_waits（需 performance_schema 启用）或手动 JOIN INNODB_TRX + PROCESSLIST 定位持锁者，而不是找不存在的 Locked_connects。
别在监控脚本里硬写 Locked_connects——它不会返回任何值，只会让告警永远静默失效。真要建锁告警，盯死 Innodb_row_lock_current_waits > 0 和 Innodb_row_lock_time_avg > 100 这两个组合条件，再辅以 TRX_STATE = 'LOCK WAIT' 的事务快照，才抓得住真实问题。
