直接查sys.innodb_lock_waits视图并关联INNODB_TRX，可快速定位阻塞链及持锁事务；若该视图为空，需联合查询INNODB_TRX与PROCESSLIST，重点筛查COMMAND='Sleep'但trx_state='RUNNING'且trx_started超时的悬挂事务。

直接结论：别查 SHOW PROCESSLIST，得用 sys.innodb_lock_waits 视图 + INNODB_TRX 关联定位，否则大概率漏掉“Sleep 却持锁”的真凶。

查 sys.innodb_lock_waits 快速拿到阻塞链

这个视图是 MySQL 5.7+ 最省力的入口，它把谁在等、谁在堵、等了多久、SQL 是什么全列出来了。执行：

SELECT * FROM sys.innodb_lock_waits\G

关键字段说明：

• blocking_pid 是真正持锁的连接 ID（不是“Waiting for …”那个）
• waiting_query 是被卡住的语句（比如一条简单 UPDATE）
• sql_kill_blocking_query 直接给你可执行的 KILL 命令，但建议先看语句再决定是否杀
• 如果返回为空，先确认 performance_schema=ON 且 sys schema 已安装（5.7 默认启用）

为什么 SHOW PROCESSLIST 找不到元凶？

因为大量行锁等待的源头根本不在 “Command = Query” 的活跃线程里，而是在那些：

• COMMAND = 'Sleep'、STATE = ''（空）、但 INFO 为空的连接
• 对应事务状态仍是 trx_state = 'RUNNING'，且 trx_started 很早（比如 > 300 秒）
• 这种连接通常来自应用异常断连后事务没自动回滚，或 BEGIN 后只跑了一条 SELECT 就挂起

必须用 JOIN 查才能揪出来：

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

SELECT t.trx_id, t.trx_started, t.trx_state, p.ID, p.USER, p.HOST, p.DB, p.COMMAND, p.TIME, p.INFO<br>FROM information_schema.INNODB_TRX t<br>JOIN information_schema.PROCESSLIST p ON t.trx_mysql_thread_id = p.ID<br>WHERE p.COMMAND = 'Sleep' AND t.trx_state = 'RUNNING'<br>ORDER BY t.trx_started;

INNODB_TRX 里哪些字段最该盯住？

光看线程 ID 不够，得结合事务上下文判断风险等级：

• trx_isolation_level = 'REPEATABLE READ'：哪怕只执行过一条 SELECT，事务一启就持 MDL 和可能的间隙锁
• trx_rows_locked > 10000 或 trx_rows_modified > 0：说明已锁大量行或正在改数据，冲突概率陡增
• trx_started 时间戳比当前时间早很多（如 > 5 分钟），基本可以判定是悬挂事务
• trx_weight 值极大（> 100000）：代表事务涉及的 undo log 条目极多，通常是大范围 UPDATE/DELETE 未提交

容易被忽略的隐性锁源

除了长事务，还有几类操作会悄悄拉高行锁等待，但不显现在常规锁视图里：

• 对无索引字段做 UPDATE/DELETE：退化成全表扫描 + 全表加记录锁，EXPLAIN 中 type = ALL 或 key = NULL 就是信号
• 使用函数或隐式转换的 WHERE 条件：如 WHERE DATE(create_time) = '2026-10-12' 或 WHERE mobile = 13800138000（mobile 是 varchar）
• information_schema 查询：某些版本中访问 TABLES 或 COLUMNS 会隐式持有 MDL_SHARED_READ，阻塞 DDL 甚至后续查询
• FLUSH TABLES WITH READ LOCK：虽属全局锁，但会阻塞所有 DML，并让后续 SELECT 等待，表现类似行锁堆积

真正难缠的从来不是正在跑的 SQL，而是那些 Sleep 着却死握着锁不放的连接——它们不会出现在 SHOW PROCESSLIST 的活跃列表里，也不会在 events_statements_current 中露头，只有靠 INNODB_TRX 和 PROCESSLIST 联合扫描才能暴露。