为什么线程有时会在 MySQL 中保持“killed”状态？

发布时间：2025-11-05 05:24:00 来源：创站工坊 作者：应用开发

问题描述

您是线程否曾经试图杀死一个查询，但它并没有消失，中保d状而是线程在运行的查询中停留了很长一段时间？或者你注意到一些被标记为被杀死的线程不时出现并且实际上并没有死亡。这些僵尸线程是中保d状什么？为什么 MySQL 有时似乎无法快速终止查询？本章对此问题进行剖析。

Threads and 线程connections

MySQL 为每个客户端连接使用单独的线程。发送到 MySQL 的中保d状查询由先前与查询的连接关联的线程处理。任何拥有足够权限的线程人都可以通过运行SHOW PROCESSLIST命令查看当前活动线程的列表以及一些其他详细信息，该命令返回一个类似表的中保d状视图，每一行都是线程个连接。具体如下：

任何正在运行的中保d状查询或列表中的任何现有连接都可以使用KILL命令进行终止。

命令语法：

KILL [QUERY | CONNECTION] <thread_id>

其中thread_id是线程来自进程列表输出的第一列的值。可选参数是中保d状只运行的查询还是终止整个会话。它默认为后者，源码下载线程因此不需要指定CONNECTION 。中保d状

运行该命令实际上并没有做任何事情，线程除了在所选线程内设置一个特殊标志。因此 kill 操作不会与相应的 request 同步发生。在许多情况下，线程或查询需要一些时间才能停止。在语句执行的各个阶段检查标志。它何时准确发生或发生频率如何，取决于线程实际正在执行的工作。

例如：

当然，这些只是香港云服务器基本示例，不同情况下，可能会有所不同。在某些情况下，某些查询甚至可能无法终止。从

线程长时间处于终止状态。这是什么意思？

实际上，可以有两种不同的情况。如果发出KILL <thread_id>，则列表中的进程将被杀死。KILL QUERY <thread_id>不会终止连接，而是只停止连接中正在运行的查询，因此在这种情况下，可能会出现查询结束文本。

如果你看到这样的东西怎么办？

它可能是错误（例如错误#52528），或者更可能是数据库在内部执行一些工作，以便任务终止后进行清理。

当然，没有简单的站群服务器方法来确认这是否是一个错误。因此，为了弄清楚它，您应该寻找证明它不是错误的证据。您所看到的只是标准操作的效果，MySQL 在查询或事务之后必须执行该操作以进行清理。

一个线程在被杀死或查询结束的情况下停留更长时间的最常见原因可能是等待InnoDB 表上的事务回滚。这有时可能需要很长时间才能完成，尤其是当必须删除数十万或数百万的更改时。

如何验证？

检查是SHOW ENGINE INNODB STATUS\G的输出。如果当前正在进行回滚，会有如下简单的信息：

复制---TRANSACTION 0 10411, ACTIVE 28 sec, process no 15506, OS thread id 140732309711184 rollback

mysql tables in use 1, locked 1 ROLLING BACK 7585 lock struct(s), heap size 751600, undo log entries 798854

MySQL thread id 14 , query id 206 localhost root end

该示例显示了如果一个线程被标记为kill或query end，并且 InnoDB 引擎状态报告同一线程的回滚，请等待它结束。

如果不是这样呢？

它可能与从磁盘中删除一些临时表有关。一个ALTER TABLE可能需要丢弃一个非常大的临时表，而在某些文件系统（例如ext3或ext4）上删除大文件可能相当慢，因此可能需要几秒钟甚至更长的时间。任何 DML 语句也可以创建临时表，但通常不会那么大。

在最极端的情况下，删除文件也不会超过十或二十秒，但在 I/O 负载较重的情况下，它可能会更长，所以有什么方法可以查看是否有临时表是否被创造？在Percona Server或MariaDB中，您检查INFORMATION_SCHEMA.GLOBAL_TEMPORARY_TABLE和INFORMATION_SCHEMA.TEMPORARY_TABLE的内容。它仅适用于使用CREATE TEMPORARY TABLE语句手动建立的临时表，不适用于 MySQL 隐式创建的执行复杂查询时的临时表。

SESSION_ID与进程列表中的线程标识符相同，因此您可以杀死任何连接到临时表的线程。

其他类型的临时表不容易追踪。有时可以在SHOW PROCESSLIST输出中发现有用信息：

有时您可以检查实例打开的临时文件：

红色标记的值是文件的大小。这些可以帮助您定位正在删除的临时表。

结论

有时看到一个数据库线程被杀死，但线程并没有立即被终止，或者一个查询似乎无法结束，这可能是正常的。因为实际操作不会与 kill 命令同步执行，之后 MySQL可能仍需要一些时间才能正确清理。不管真正的原因是什么，如果不重新启动数据库，就不可能摆脱这种挂起的线程。也没有办法像Unix 系统中的kill -9 <pid>那样立即强制执行kill。

相关文章