答案是慢查询日志不记录锁等待本身，只将等待时间计入总执行时间；需结合performance_schema.data_lock_waits或information_schema.INNODB_LOCK_WAITS等实时视图定位阻塞链，再通过Rows_examined小但Query_time大、Rows_sent为0等日志特征辅助判断锁争用。
MySQL慢查询日志里看不到锁等待，但SQL就是卡住：先确认是否真被锁了
慢查询日志（slow_query_log）只记录执行时间超过 long_query_time 的语句，**不记录锁等待本身**。如果你看到某条 UPDATE 或 SELECT ... FOR UPDATE 在慢日志里耗时很长，但实际语句很简单（比如 UPDATE t SET a=1 WHERE id=100），大概率是它在等行锁或表锁——而这个“等待时间”会计入总执行时间，但日志里不会告诉你“等了 3.2 秒才拿到 InnoDB 行锁”。
所以第一步不是翻日志，而是查当前阻塞链：
- 连上 MySQL 后立刻执行 SELECT * FROM performance_schema.data_lock_waits（8.0+）或 SELECT * FROM information_schema.INNODB_TRX\G + INNODB_LOCKS + INNODB_LOCK_WAITS（5.7 及更早）；
- 关键看 TRX_WAITING 和 TRX_BLOCKING_TRX_ID 字段；
- 如果发现有事务长时间处于 LOCK WAIT 状态，再结合慢日志里那条 SQL 的 query_time，基本能锁定是锁争用而非 SQL 本身低效。
MyISAM 和 InnoDB 锁行为差异会直接改变慢日志“嫌疑名单”
引擎不同，锁粒度和持有时机完全不同，这直接影响哪些 SQL 容易进慢日志：
- MyISAM 只支持表级锁：
SELECT会加读锁（阻塞写），UPDATE/DELETE/INSERT加写锁（阻塞所有读写）；哪怕你只更新一行，整张表都可能被锁住，导致后续大量简单查询排队——这些查询在慢日志里表现为“执行时间突增”，但实际执行逻辑极快，只是前面卡着一个未提交的UPDATE。 - InnoDB 默认行级锁，但**某些场景会升级为间隙锁（Gap Lock）或临键锁（Next-Key Lock）**：比如
WHERE name > 'Alice'没走索引，或走了范围索引但没命中唯一值，就可能锁住一大片区间；这时另一个事务想插入中间值就会被堵住，对应 SQL 出现在慢日志里，但 explain 显示走了索引，让人误判。 - 特别注意：MyISAM 不支持事务，
ROLLBACK无效；一旦有长事务（其实是长操作）卡住表锁，只能 kill 进程；而 InnoDB 的锁超时由innodb_lock_wait_timeout控制（默认 50 秒），超时后报错Lock wait timeout exceeded，这条失败 SQL 通常不会进慢日志（因为没跑完），但它的上游等待者会进。
从慢日志定位“疑似锁问题”的三条实操线索
别只盯着 query_time，结合其他字段交叉判断：
-
Rows_examined很小（比如 1 或 10），但query_time很大（>1s）→ 强烈提示锁等待，而非扫描慢； -
Rows_sent为 0，query_time却很高 → 可能是UPDATE/DELETE卡在锁上，还没开始改数据； - 同一条 SQL 在慢日志中反复出现，且
timestamp时间戳密集连续 → 很可能是多个会话在排队等同一个资源（如热点行、自增主键竞争、唯一索引冲突重试）。
示例：慢日志片段
MySQL 数据库管理技能，能够通过自然语言查询和管理数据库，支持 SELECT/INSERT/UPDATE/DELETE、表管理、备份恢复等操作。当用户提及 MySQL、数据库查询、建表或数据备份时使用此技能。
# Time: 2024-06-15T14:22:33.123456Z # User@Host: app[app] @ 10.0.1.5 [10.0.1.5] # Query_time: 4.231245 Lock_time: 0.000123 Rows_sent: 0 Rows_examined: 1 use mydb; UPDATE orders SET status = 'shipped' WHERE order_id = 123456;
这里 Rows_examined: 1 说明索引有效，Lock_time 极短但 Query_time 很长，基本可断定是等锁。
验证锁问题时最容易忽略的两个点
一是 innodb_status_output 和 innodb_status_output_locks 必须打开，否则 SHOW ENGINE INNODB STATUS\G 不显示锁详情；二是很多团队只查慢日志里的 SQL 文本，却漏掉客户端 IP 和用户（User@Host 字段），而实际锁冲突往往发生在同一应用的不同实例之间（比如两个 PHP-FPM 进程同时处理同一订单），IP 和账号对齐后才能还原完整调用链。
真正难的不是发现锁，而是确认谁持有了锁却不释放——它可能是个没提交的事务，也可能是个 sleep 中的连接，还可能是个异常中断但连接没断开的旧会话。这时候得靠 information_schema.PROCESSLIST 结合 TRX_STARTED 时间反查。
