mysql 8.0 中 information_schema.innodb_locks 表已被移除，应改用 performance_schema.data_locks；需先启用相关 instruments 和 consumers，否则查询返回空。

MySQL 8.0 查 information_schema.innodb_locks 返回空怎么办

直接查不到，不是你权限或语法错，是这张表在 MySQL 8.0 中已被移除。官方文档明确标注为“deprecated since 5.7, removed in 8.0”。哪怕你执行 SELECT * FROM information_schema.innodb_locks; 不报错，也只会返回空结果集。

常见误操作是照着老教程或 5.7 环境下的笔记硬套——比如看到 lock_mode: X、lock_table: `test`.`t1` 这类字段就以为还能用。实际上，8.0 起所有锁对象信息已统一迁移到 performance_schema.data_locks。

• 确认版本：运行 SELECT VERSION();，若输出以 8. 开头，就别再查 innodb_locks
• 替代方案必须启用 instrumentation：执行 UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' WHERE NAME LIKE '%wait/lock%';
• 检查是否已开采集：运行 SELECT VARIABLE_VALUE FROM performance_schema.setup_consumers WHERE NAME = 'global_instrumentation';，结果必须是 YES

MySQL 5.7 怎么用 innodb_locks 和 innodb_lock_waits 定位阻塞者

这两张表在 5.7 是有效的联动组合，但要注意字段语义和查询顺序——不能只查一张表就下结论。

innodb_locks 只告诉你“有哪些锁”，不说明谁在等、谁在占；innodb_lock_waits 才给出等待关系，但它只存 ID（如 blocking_trx_id），得回查 innodb_trx 才知道那个事务干了什么、卡了多久。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

• 先筛等待中的事务：SELECT * FROM information_schema.INNODB_TRX WHERE trx_state = 'LOCK WAIT'\G;，重点看 trx_wait_started 和 trx_query
• 再查谁挡路：SELECT * FROM information_schema.INNODB_LOCK_WAITS\G;，拿到 blocking_trx_id
• 最后定位源头：SELECT trx_id, trx_mysql_thread_id, trx_started, trx_state, trx_query FROM information_schema.INNODB_TRX WHERE trx_id = '613962';（把上面查到的 ID 填进去）
• 注意权限：普通账号默认看不到其他用户的事务，需被授予 PROCESS 权限

SHOW STATUS LIKE 'innodb_row_lock_current_waits' 为什么值为 0 却还有卡住的 SQL

这个状态变量只反映“此刻正在发生的行级锁等待”瞬时快照，归零不代表没锁问题——它可能刚释放、也可能根本不是行锁问题。

典型误判场景：DDL 操作卡在 Waiting for table metadata lock，这是元数据锁（MDL），跟 InnoDB 行锁完全无关，innodb_row_lock_* 系列变量对它毫无反应。

• 查 MDL 锁要换路子：看 performance_schema.metadata_locks 或结合 show processlist 状态字段
• 如果 innodb_row_lock_current_waits 长期为 0，但 innodb_row_lock_time_avg 突然飙升（比如从 0.1ms 到 40ms+），说明有短时密集争用，得盯紧应用层事务提交节奏
• 这个指标不体现锁类型细节，仅作初筛；真要定位，必须进 INNODB_TRX 或 data_locks

为什么查到 trx_state = 'RUNNING' 却没 trx_query 就该警惕

这种事务大概率是“挂着没死、但早该结束了”——比如应用异常断连后未 rollback，或代码里漏了 COMMIT/ROLLBACK。它持续持有锁，却不在执行任何 SQL，是锁等待链最常出现的源头。

尤其在 RR 隔离级别下，一个 SELECT ... FOR UPDATE 后没提交，锁会一直占着；RC 下虽部分锁释放快，但唯一键冲突检查引发的 gap lock 仍可能残留。

• 快速筛查语句：SELECT trx_id, trx_mysql_thread_id, trx_started, trx_state, trx_query FROM information_schema.INNODB_TRX WHERE trx_state = 'RUNNING' AND (trx_query IS NULL OR trx_query = '') ORDER BY trx_started ASC LIMIT 10;
• 别急着 KILL：先用 SELECT * FROM performance_schema.threads WHERE THREAD_ID = ? 查对应连接的 PROCESSLIST_INFO，排除监控探针或定时任务的“假活跃”
• 真正麻烦的是那种 trx_operation_state 显示 'sleeping before entering InnoDB' 的事务——它已脱离 SQL 执行阶段，但锁还攥着