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”问题，需要分析数据库状态指标，日志，资源使用情况和关联业务场景。

解决方法

解决方案需根据具体原因针对性处理：

• 优化查询语句：通过更改查询语句，尽可能减少子查询、联接操作或数据量，可以有效地缩短查询时间。这样可以避免MySQL进程一直处于“query end”状态。

• 优化数据库结构：通过对数据库表的索引和分区进行优化，可以加快查询速度。这有助于避免MySQL服务器进程一直处于“query end”状态。

• 增加服务器资源：如果MySQL服务器没有足够的内存或CPU资源来处理查询，则需要考虑增加服务器资源。可以通过升级硬件或使用云计算解决方案等方式来增加服务器资源。

• 调整参数设置：通过调整MySQL服务器的参数设置，例如增加等待超时时间，可以避免锁等待导致MySQL进程一直处于“query end”状态。

内部实现和Bug导致

此外，有实际案例和官方bug报告中提到InnoDB事务系统的内部延迟。

• 有网上经验分享指出，在IO负载高的情况下，query end 状态耗时过长可能与事务日志的刷盘机制直接相关。这是需要调整sync_binlog和innodb_flush_log_at_trx_commit 参数，缩短该状态的耗时。

• 官方Bug报告：MySQL官方Bug追踪系统中存在关于连接永远卡在 query end 状态的报告（Bug #91078）。报告指出，出现此问题时，KILL 命令无效，有时只能通过重启服务器解决。其提供的线程堆栈跟踪显示，线程可能卡在等待进入InnoDB内核的状态，这指向了存储引擎内部或与服务器层交互时的潜在问题。

总结

MySQL进程一直处于“query end”状态可能是由于复杂的查询语句、锁等待或资源限制等原因引起的。通过合理地调整和优化，可以避免MySQL进程一直处于“query end”状态，从而保证MySQL服务器的稳定性和可靠性。