MySQL慢查询场景下Query_time长但Lock_time短的问题咨询

云上老周

2026-10-5

问题核心特征分析

这条UPDATE语句按主键ID过滤，仅扫描1行，Lock_time仅0.000261s说明语句获取锁的过程几乎无等待，耗时全部发生在获取锁之后的执行、提交阶段，常见原因如下：

可能的原因

InnoDB刷脏页阻塞：如果当时InnoDB缓冲池脏页比例过高，或刚好遇到redo log写满触发强制checkpoint、后台大规模刷脏，IO资源被占满，该UPDATE修改完缓冲池中的页后，需要等待相关脏页刷入磁盘才能完成提交，会导致耗时陡增。如果innodb_io_capacity设置远低于磁盘实际IO能力，这类问题出现的概率会更高。
事务提交阶段刷盘等待：若数据库开启了innodb_flush_log_at_trx_commit=1 + sync_binlog=1的双1高安全配置，每次事务提交都需要等待redo log、binlog持久化到磁盘。如果当时有大量并发事务提交，会出现组提交竞争，磁盘fsync性能不足时会导致提交阶段耗时大幅拉长，这部分耗时会被计入Query_time但不会计入Lock_time。
隐式关联操作开销：检查submissions表是否存在UPDATE类型的触发器，或其他表将该表id作为外键并配置了级联更新规则。这类隐式执行的额外逻辑不会体现在Lock_time统计中，如果关联操作涉及大表查询、更新，会直接拉高总执行时长。
大字段存储带来的IO开销：如果submissions表包含TEXT、BLOB等大字段，即使你更新的不是大字段，InnoDB聚簇索引的存储特性也需要读取完整行所在的数据页，修改后再刷回磁盘。若行体积本身很大，加上当时磁盘IO负载较高，也会导致单条更新耗时极高。
磁盘硬件/负载问题：排查语句执行时刻的磁盘监控，若当时iowait长期高于20%、磁盘使用率持续100%，或存在磁盘坏道等硬件故障，所有IO操作都会被拖慢，直接导致更新耗时变长。