MySQL InnoDB 怎样查看锁等待事务

MySQL InnoDB 出现“请求卡住、事务迟迟不结束”时，先不要直接执行 KILL。在 MySQL 8.4 中，可以先查询 sys.innodb_lock_waits，快速看到等待事务和阻塞事务；如果需要确认具体锁在哪张表、哪个索引上，再关联 performance_schema.data_locks 与 data_lock_waits。当阻塞会话已经变成空闲、阻塞 SQL 显示为 NULL 时，还要沿着 blocking_pid 查询 Performance Schema 的线程和语句历史。

最短路径是先看 sys.innodb_lock_waits 的 waiting/blocking 两侧，再用锁资源表确认对象，最后根据业务归属决定提交、回滚或终止会话。锁等待是事务之间的阻塞关系，不等同于已经发生死锁。

• 先定位关系：找出谁在等、谁在挡，以及双方当前能看到的 SQL。
• 再定位资源：确认 schema、表、索引、锁类型和请求/持有状态。
• 最后做处置：先确认事务是否属于正在执行的业务，再选择让持锁事务正常结束或按应急流程处理。

先判断：这是锁等待还是另一类慢问题

锁等待通常表现为某个事务状态进入 LOCK WAIT，请求的锁需要等另一个事务提交或回滚后才能继续。MySQL 官方文档把 INNODB_TRX、data_locks 和 data_lock_waits 作为观察 InnoDB 事务与锁关系的主要表：前者描述正在执行的 InnoDB 事务，后两者描述锁以及等待和阻塞之间的对应关系。

排查时可以先把现象分成三类：

这个区分很重要：锁等待查询回答的是“谁阻塞了谁”，并不直接回答“为什么业务事务长时间不提交”。后一个问题还要回到事务边界、应用连接池和具体 SQL。

用 sys.innodb_lock_waits 快速查看等待事务

如果实例启用了随 MySQL 提供的 sys schema，优先执行下面的查询。它把官方示例中需要手动关联的事务关系整理成了更容易阅读的视图。

-- 先查看当前等待方和阻塞方，示例只读系统视图
SELECT
    waiting_trx_id,
    waiting_pid,
    waiting_query,
    blocking_trx_id,
    blocking_pid,
    blocking_query
FROM sys.innodb_lock_waits
ORDER BY wait_started;

重点看四组字段：

• waiting_trx_id 与 waiting_pid：正在等待锁的 InnoDB 事务和 MySQL 进程列表 ID。
• waiting_query：等待方当前能看到的语句，适合先确认业务动作。
• blocking_trx_id 与 blocking_pid：持有冲突锁、导致等待无法继续的事务和会话 ID。
• blocking_query：阻塞方当前语句；如果会话已经空闲，这一列可能是 NULL。

例如结果中出现 waiting PID 为 421、blocking PID 为 388，只能说明 421 当前被 388 的冲突锁挡住。不要仅凭 PID 大小、连接时间或一条 SQL 文本判断谁“更应该”被终止，还需要看事务归属、持锁时间和业务影响。

用 Performance Schema 展开具体锁资源

当需要知道等待的是哪张表、哪个索引或哪种锁模式时，直接查看 data_lock_waits，再分别关联请求锁和阻塞锁对应的 data_locks 行。下面的查询保留了请求与持有两侧的关键列。

-- 用请求锁 ID 和阻塞锁 ID 展开锁对象，避免只看到事务编号
SELECT
    w.REQUESTING_ENGINE_TRANSACTION_ID AS waiting_trx_id,
    req.OBJECT_SCHEMA AS waiting_schema,
    req.OBJECT_NAME AS waiting_table,
    req.INDEX_NAME AS waiting_index,
    req.LOCK_TYPE AS waiting_lock_type,
    req.LOCK_MODE AS waiting_lock_mode,
    w.BLOCKING_ENGINE_TRANSACTION_ID AS blocking_trx_id,
    hold.OBJECT_SCHEMA AS blocking_schema,
    hold.OBJECT_NAME AS blocking_table,
    hold.INDEX_NAME AS blocking_index,
    hold.LOCK_TYPE AS blocking_lock_type,
    hold.LOCK_MODE AS blocking_lock_mode
FROM performance_schema.data_lock_waits AS w
JOIN performance_schema.data_locks AS req
  ON req.ENGINE_LOCK_ID = w.REQUESTING_ENGINE_LOCK_ID
JOIN performance_schema.data_locks AS hold
  ON hold.ENGINE_LOCK_ID = w.BLOCKING_ENGINE_LOCK_ID
ORDER BY waiting_trx_id;

这里的判断顺序是：先看 OBJECT_SCHEMA 和 OBJECT_NAME 是否对应预期业务表，再看 INDEX_NAME、LOCK_TYPE 和 LOCK_MODE。官方说明中，data_lock_waits 的请求锁 ID 指向等待方申请的锁，阻塞锁 ID 指向阻止请求继续的已持有锁；一个等待事务也可能对应多条阻塞关系。

如果只想确认当前有哪些事务在等待，也可以先用下面的轻量查询，把 LOCK WAIT 的事务、线程和等待开始时间列出来：

-- 先按等待开始时间观察最早进入 LOCK WAIT 的事务
SELECT
    trx_id,
    trx_state,
    trx_started,
    trx_wait_started,
    trx_mysql_thread_id,
    trx_query
FROM information_schema.innodb_trx
WHERE trx_state = 'LOCK WAIT'
ORDER BY trx_wait_started;

blocking_query 为空时怎样追溯原始语句

阻塞事务所在的客户端可能已经执行完上一条语句，但还没有提交或回滚事务。此时 sys.innodb_lock_waits.blocking_query 显示 NULL 并不代表没有阻塞，只表示当前没有可直接展示的正在执行语句。

官方给出的追溯路径是：先取 blocking_pid，再从 performance_schema.threads 找到内部 THREAD_ID，然后查看当前语句或历史语句。

-- 先把下面的 388 替换为查询结果里的 blocking_pid
SELECT
    THREAD_ID,
    PROCESSLIST_ID,
    PROCESSLIST_USER,
    PROCESSLIST_DB,
    PROCESSLIST_COMMAND
FROM performance_schema.threads
WHERE PROCESSLIST_ID = 388;

-- 再把返回的 THREAD_ID 替换到这里，查看当前语句
SELECT THREAD_ID, SQL_TEXT
FROM performance_schema.events_statements_current
WHERE THREAD_ID = 12345;

-- 当前语句不足以判断时，再看该线程最近记录的语句
SELECT THREAD_ID, EVENT_ID, SQL_TEXT
FROM performance_schema.events_statements_history
WHERE THREAD_ID = 12345
ORDER BY EVENT_ID DESC
LIMIT 10;

示例里的 388 和 12345 只是占位值，实际排查必须替换成同一时刻查询出的 ID。若语句历史没有记录，也不能据此断定事务没有风险，还应结合事务开始时间、应用日志、连接归属和业务操作记录继续判断。

确认原因后再决定如何处理

看到阻塞关系后，处理动作要围绕持锁事务展开，而不是先处理等待方。可以按下面顺序缩小风险：

1. 确认影响：记录等待方数量、最早等待时间、受影响接口或任务，判断是否已经达到应急阈值。
2. 确认归属：根据 blocking_pid、数据库用户、客户端地址和应用日志确认会话属于哪个服务或人工操作。
3. 优先让事务正常结束：如果业务允许，优先让持锁事务提交或回滚；应用侧要检查是否遗漏了提交、回滚或连接归还。
4. 必要时走应急流程：只有在明确业务负责人和回滚影响后，才按现场规范终止阻塞会话。终止连接可能触发回滚，回滚本身也会持续一段时间。
5. 复查关系：重新执行 sys.innodb_lock_waits，确认等待行消失，并检查应用请求是否恢复；不要把一次查询为空当成根因已经修复。

排查期间不要直接修改系统表，也不要把示例中的 PID 当作固定值。会话退出、连接重建和事务回滚都会改变观察结果，处置记录应保留查询时间、事务 ID、线程 ID、业务归属和最终动作。

一份可复用的锁等待排查清单

最终可以把结论压缩成一句话：sys.innodb_lock_waits 负责快速回答“谁等谁”，data_lock_waits 和 data_locks 负责回答“等的是哪个锁”，Performance Schema 语句表负责补上“阻塞会话之前做了什么”。三层信息结合起来，才足够支持后续的业务处置。

常见问题

sys.innodb_lock_waits 查不到数据，是不是没有锁问题？

它只反映查询时刻仍存在的锁等待。如果等待已经结束、实例没有相应权限，或问题实际是 CPU、IO、网络和执行计划导致的慢查询，都可能查不到行。应结合 INNODB_TRX、应用超时记录和数据库监控同时判断。

锁等待和死锁有什么区别？

锁等待是一个事务等待另一个事务释放冲突锁；死锁通常表现为事务之间形成环路，InnoDB 可能主动回滚其中一个事务。锁等待查询可以帮助发现阻塞关系，但不能单独替代死锁日志分析。

blocking_query 为 NULL 时应该立即 KILL 吗？

不应该仅因这一列为空就终止会话。先用 blocking_pid 查询线程和语句历史，确认事务归属、持锁时间和业务影响，再按应急流程决定提交、回滚或终止。