MySQL中 query end状态详解及问题排查

mahan

MySQL中，执行SHOW Processlist时，State状态值包含“query end”。通常，“query end”状态应短暂，但有长时间停留在 “query end” 状态，这个情况会导致MySQL服务不稳定甚至无响应。下面深入解析“query end”状态及其可能原因。

什么是“query end”状态
在MySQL中，query end状态是 MySQL执行语句生命周期的最后一个阶段，该阶段通常耗时极短（毫秒级）。按照官方提供的说明：

#query end
This state occurs after processing a query but before the freeing items state.
此状态发生在处理查询之后，但在释放项目状态之前。就是说
连接 -> 解析SQL -> 优化 -> 执行 -> [query end] -> 清理
“query end” 就处在 “执行” 之后，“清理” 之中的这个阶段。比如：

释放临时表。
关闭打开的表句柄
释放锁。
清理查询缓存（如果启用）
发送结果给客户端。
与 “Sending data” 状态的区别
这是一个非常重要的区别：

Sending data： 这个状态表示线程正在读取存储引擎的数据，并进行连接、排序、过滤等核心计算。这是查询的“重活”阶段，CPU 和磁盘 I/O 可能很高。

query end： 这个状态表示核心计算已经完成，线程正在做收尾工作（清理、传输结果）。这个阶段通常不涉及大量的数据计算，但可能受网络速度影响。

常见原因
若"query end"状态持续时间超过3秒，需立即排查潜在瓶颈，避免服务雪崩。常见原因如下：

查询耗时过长：当查询语句包含复杂的子查询、联接操作或大量数据时，可能需要很长时间才能完成查询。此时，MySQL进程可能会一直处于“query end”状态，直到查询完成为止。

锁等待：如果MySQL进程正在等待其他进程释放锁，它也可能会保持在“query end”状态。这通常发生在高并发环境下，多个进程同时尝试访问同一组数据时容易出现。

硬件资源竞争：如果MySQL服务没有足够的内存，硬盘 或 CPU资源来处理收尾工作，进程可能会一直处于“query end”状态。

参数设置不合理：全局内存，表缓存，临时表大小过小，双1配置。导致调用资源排队。

排查流程
排查“query end”问题，需要分析数据库状态指标，日志，资源使用情况和关联业务场景。

登录/注册后可看大图