如何通过MySQL慢查询日志发现潜在的事务锁定性能瓶颈？

Lock_time高但Query_time低说明事务被锁阻塞，根本原因是间隙锁或锁升级，需检查非唯一索引的范围查询、调整隔离级别、关闭log_queries_not_using_indexes并用pt-query-digest按Lock_time过滤分析。

Lock_time 高但 Query_time 低，说明事务被堵住了

慢查询日志里出现 Lock_time 明显偏高（比如 >0.5s），而 Query_time 却不高（比如 Rows_examined 很小。

这时候别急着优化 SQL 或加索引——先查谁在 hold lock。

1. 立刻执行 SELECT * FROM information_schema.INNODB_TRX，看 TRX_STATE = 'RUNNING' 且 TRX_STARTED 时间很早的事务
2. 配合 SELECT * FROM information_schema.INNODB_LOCK_WAITS 找出等待链：哪个事务在等哪个事务释放哪把锁
3. 注意 TRX_MYSQL_THREAD_ID，用它去 SHOW PROCESSLIST 查对应连接的原始 SQL 和状态

日志里反复出现同一类 UPDATE/DELETE 语句，大概率是行锁升级或间隙锁冲突

比如日志中高频出现类似 UPDATE orders SET status = ? WHERE user_id = ? AND id > ? 的语句，且 Lock_time 持续在 100ms~500ms 区间波动，说明不是单条记录锁争抢，而是范围条件触发了间隙锁（gap lock）或锁升级（如从行锁升为表锁）。

这类问题不会在 EXPLAIN 里暴露，因为执行计划看起来没问题，但实际加锁范围远超预期。

1. 检查 WHERE 条件是否含非唯一索引字段 + 范围查询（如 WHERE status = 'pending' AND created_at > '2026-06-01'）
2. 确认隔离级别：REPEATABLE READ 下间隙锁更激进，READ COMMITTED 可缓解但不解决根本
3. 临时验证：对关键更新语句加 FOR UPDATE 显式锁，并控制事务粒度——避免在事务里混杂 SELECT + UPDATE

log_queries_not_using_indexes = ON 会掩盖真正的锁瓶颈

这个参数一开，所有没走索引的查询都会进慢日志，哪怕它执行飞快。结果就是 Lock_time 高的真问题被淹没在一堆“没索引但很快”的噪音里，排查效率断崖下跌。

定位锁问题时，建议关掉它，专注抓 Lock_time / Query_time > 0.3 的有效样本。

1. 临时关闭：SET GLOBAL log_queries_not_using_indexes = OFF
2. 同时调低 long_query_time 到 0.1，确保能捕获短时但高锁等待的语句
3. 日志路径必须有写权限——如果 MySQL 运行用户（如 mysql）对 slow_query_log_file 所在目录无写权限，日志静默失败，Lock_time 数据根本不会落盘

pt-query-digest 分析时必须加 --filter 过滤 Lock_time

pt-query-digest 默认按 Query_time 排序，对锁瓶颈毫无帮助。直接跑 pt-query-digest /var/log/mysql/mysql-slow.log 会优先列出耗时长的聚合查询，而真正卡住系统的短事务可能排不进 Top 10。

要用过滤器把锁等待单独拎出来：

1. pt-query-digest --filter '$event->{Lock_time} > 0.2' /var/log/mysql/mysql-slow.log
2. 再加 --order-by 'sum(Lock_time)' 看累计锁等待最高的语句
3. 注意时区：# Time: 时间戳默认用系统时区，若业务日志用 UTC，需手动对齐，否则关联不到具体请求

真实锁瓶颈往往藏在“快 SQL”里，而不是慢日志里最耗时的那几条。盯住 Lock_time 与 Query_time 的比值，比单纯看耗时更能反映并发真实压力。