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。
- 立刻执行
SELECT * FROM information_schema.INNODB_TRX，看TRX_STATE = 'RUNNING'且TRX_STARTED时间很早的事务 - 配合
SELECT * FROM information_schema.INNODB_LOCK_WAITS找出等待链：哪个事务在等哪个事务释放哪把锁 - 注意
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 里暴露，因为执行计划看起来没问题，但实际加锁范围远超预期。
- 检查 WHERE 条件是否含非唯一索引字段 + 范围查询（如
WHERE status = 'pending' AND created_at > '2026-06-01'） - 确认隔离级别：
REPEATABLE READ下间隙锁更激进，READ COMMITTED可缓解但不解决根本 - 临时验证：对关键更新语句加
FOR UPDATE显式锁，并控制事务粒度——避免在事务里混杂 SELECT + UPDATE
log_queries_not_using_indexes = ON 会掩盖真正的锁瓶颈
这个参数一开，所有没走索引的查询都会进慢日志，哪怕它执行飞快。结果就是 Lock_time 高的真问题被淹没在一堆“没索引但很快”的噪音里，排查效率断崖下跌。
定位锁问题时，建议关掉它，专注抓 Lock_time / Query_time > 0.3 的有效样本。
- 临时关闭：
SET GLOBAL log_queries_not_using_indexes = OFF - 同时调低
long_query_time到0.1，确保能捕获短时但高锁等待的语句 - 日志路径必须有写权限——如果 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。
要用过滤器把锁等待单独拎出来：
pt-query-digest --filter '$event->{Lock_time} > 0.2' /var/log/mysql/mysql-slow.log- 再加
--order-by 'sum(Lock_time)'看累计锁等待最高的语句 - 注意时区：
# Time:时间戳默认用系统时区，若业务日志用 UTC，需手动对齐，否则关联不到具体请求
真实锁瓶颈往往藏在“快 SQL”里，而不是慢日志里最耗时的那几条。盯住 Lock_time 与 Query_time 的比值，比单纯看耗时更能反映并发真实压力。
