高lock_time表明查询主要卡在锁等待而非执行本身；若lock_time接近query_time且rows_examined很小，说明几乎全在等锁，需立即查performance_schema.data_lock_waits或innodb_trx/innodb_lock_waits定位持锁事务。
慢查询日志里出现高 Lock_time 值，或 Query_time 明显大于 Lock_time + 实际执行耗时（比如 Rows_examined 很小但查询却卡了数秒），基本就能断定是锁竞争拖慢的。
怎么看 slow log 里有没有锁等待？
打开日志文件，找形如 # Query_time: 2.345678 Lock_time: 2.341234 Rows_sent: 1 Rows_examined: 10 的行。关键看两点：
-
Lock_time接近甚至等于Query_time，说明几乎全在等锁 -
Rows_examined很小（比如 1 或 10），但Query_time却有几百毫秒以上，排除了扫描开销，剩下就是锁
注意：默认配置下 Lock_time 不一定记录——必须确保 long_query_time 已设为合理值（如 0.1），且 MySQL 版本 ≥ 5.6；旧版本或阈值过高时，即使锁等了 1 秒，只要总耗时没超阈值，整条记录都不会进日志。
为什么 mysqldumpslow 会漏掉锁线索？
mysqldumpslow 默认只按 SQL 文本归一化（比如把 WHERE id = 123 变成 WHERE id = N），但它不合并 Lock_time。结果就是：同一条 SQL，一次等锁 2 秒、一次执行 0.01 秒，会被算作两条“不同”慢查询，锁问题就被稀释掉了。
实操建议：
- 先用
grep 'Lock_time:' /var/log/mysql/slow.log | awk '{print $2, $4}' | sort -nr | head -20直接提取前 20 名锁等待最长的记录 - 别依赖
-s t（按总耗时排），改用awk或sed抽出Lock_time字段单独分析 - 确认日志格式含
Lock_time：如果日志里只有Query_time和Rows_examined，说明 MySQL 版本太低或long_query_time没生效
查到高 Lock_time 后，怎么定位谁在持锁？
日志只告诉你“被锁了”，不告诉你“被谁锁”。这时候要立刻连上数据库查实时状态：
- 运行
SELECT * FROM performance_schema.data_lock_waits;（MySQL 8.0+）或SELECT * FROM information_schema.INNODB_TRX\G配合INNODB_LOCKS（5.7） - 重点看
TRX_WAITING状态的事务，比对它的TRX_MYSQL_THREAD_ID和blocking_trx_id - 用
SELECT * FROM performance_schema.threads WHERE THREAD_ID = xxx;查出阻塞方的 SQL 和用户
注意：INNODB_TRX 中的 TRX_QUERY 可能为空（事务空闲等待中），不能只靠它判断；得结合 TRX_STATE = LOCK WAIT 和 TRX_STARTED 时间戳，找出最早那个“不动”的事务。
log_slow_verbosity = 'full' 有什么实际价值？
MySQL 8.0.26+ 开启 log_slow_verbosity='full' 后，slow log 会额外记下 InnoDB 层的锁等待详情，例如：
# Time: 2026-06-09T03:12:44.123456Z # User@Host: app[app] @ 10.0.1.5 [10.0.1.5] Id: 12345 # Query_time: 1.234567 Lock_time: 1.234123 Rows_sent: 0 Rows_examined: 0 # InnoDB: lock wait timeout exceeded; try restarting transaction # Schema: test Last_errno: 1205 Killed: 0 # Query: UPDATE user SET status = 1 WHERE id = 12345
这种日志能直接告诉你是不是死锁、是否超时、哪个表哪行被争抢。但要注意：
- 它不会自动开启，必须显式设置
SET GLOBAL log_slow_verbosity = 'full'; - 和
log_output = TABLE不兼容，只能写入文件（FILE） - 日志体积明显增大，生产环境建议只在排查期临时开，别长期开着
真正难的不是发现锁等待，而是区分「短暂争抢」和「持续阻塞」——前者可能只是热点更新冲突，后者往往意味着事务没提交、应用层连接池泄漏，或一个长事务 hold 住了整个业务表。
