脚本之家 服务器常用软件
快捷导航
您的位置：首页 → 数据库 → Mysql → MySQL kill线程

MySQL kill不掉线程的原因

 更新时间：2021年05月07日 11:45:05   作者：王文安  
这篇文章主要介绍了MySQL kill不掉线程的原因，帮助大家更好的理解和学习使用MySQL数据库，感兴趣的朋友可以了解下

背景

在日常的使用过程中，时不时会遇到个别，或者大量的连接堆积在 MySQL 中的现象，这时一般会考虑使用 kill 命令强制杀死这些长时间堆积起来的连接，尽快释放连接数和数据库服务器的 CPU 资源。

问题描述

在实际操作 kill 命令的时候，有时候会发现连接并没有第一时间被 kill 掉，仍旧在 processlist 里面能看到，但是显示的 Command 为 Killed，而不是常见的 Query 或者是 Execute 等。例如：

mysql> show processlist;
+----+------+--------------------+--------+---------+------+--------------+---------------------------------+
| Id | User | Host               | db     | Command | Time | State        | Info                            |
+----+------+--------------------+--------+---------+------+--------------+---------------------------------+
| 31 | root | 192.168.1.10:50410 | sbtest | Query   |    0 | starting     | show processlist                |
| 32 | root | 192.168.1.10:50412 | sbtest | Query   |   62 | User sleep   | select sleep(3600) from sbtest1 |
| 35 | root | 192.168.1.10:51252 | sbtest | Killed  |   47 | Sending data | select sleep(100) from sbtest1  |
| 36 | root | 192.168.1.10:51304 | sbtest | Query   |   20 | Sending data | select sleep(3600) from sbtest1 |
+----+------+--------------------+--------+---------+------+--------------+---------------------------------+

原因分析

遇事不决先翻官方文档，这里摘取部分官方文档的内容：

When you use KILL, a thread-specific kill flag is set for the thread. In most cases, it might take some time for the thread to die because the kill flag is checked only at specific intervals:During SELECT operations, for ORDER BY and GROUP BY loops, the flag is checked after reading a block of rows. If the kill flag is set, the statement is aborted.
      ALTER TABLE operations that make a table copy check the kill flag periodically for each few copied rows read from the original table. If the kill flag was set, the statement is aborted and the temporary table is deleted.
      The KILL statement returns without waiting for confirmation, but the kill flag check aborts the operation within a reasonably small amount of time. Aborting the operation to perform any necessary cleanup also takes some time.
      During UPDATE or DELETE operations, the kill flag is checked after each block read and after each updated or deleted row. If the kill flag is set, the statement is aborted. If you are not using transactions, the changes are not rolled back.
      GET_LOCK() aborts and returns NULL.
      If the thread is in the table lock handler (state: Locked), the table lock is quickly aborted.
      If the thread is waiting for free disk space in a write call, the write is aborted with a “disk full” error message.

官方文档第一段就很明确的说清楚了 kill 的作用机制：会给连接的线程设置一个线程级别的 kill 标记，等到下一次“标记检测”的时候才会生效。这也意味着如果下一次“标记检测”迟迟没有发生，那么就有可能会出现问题描述中的现象。

官方文档中列举了不少的场景，这里根据官方的描述列举几个比较常见的问题场景：

  • select 语句中进行 order by，group by 的时候，如果服务器 CPU 资源比较紧张，那么读取/获取一批数据的时间会变长，从而影响下一次“标记检测”的时间。
  • 对大量数据进行 DML 操作的时候，kill 这一类 SQL 语句会触发事务回滚（InnoDB引擎），虽然语句被 kill 掉了，但是回滚操作也会非常久。
  • kill alter 操作时，如果服务器的负载比较高，那么操作一批数据的时间会变长，从而影响下一次“标记检测”的时间。
  • 其实参考 kill 的作用机制，做一个归纳性的描述的话，那么：任何阻塞/减慢 SQL 语句正常执行的行为，都会导致下一次“标记检测”推迟、无法发生，最终都会导致 kill 操作的失败。

模拟一下

这里借用一个参数innodb_thread_concurrency来模拟阻塞 SQL 语句正常执行的场景：

Defines the maximum number of threads permitted inside of InnoDB. A value of 0 (the default) is interpreted as infinite concurrency (no limit). This variable is intended for performance tuning on high concurrency systems.

参照官方文档的描述，这个参数设置得比较低的时候，超过数量限制的 InnoDB 查询会被阻塞。因此在本次模拟中，这个参数被设置了一个非常低的值。

mysql> show variables like '%innodb_thread_concurrency%';
+---------------------------+-------+
| Variable_name             | Value |
+---------------------------+-------+
| innodb_thread_concurrency | 1     |
+---------------------------+-------+
1 row in set (0.00 sec)

然后开两个数据库连接（Session 1 和 Session 2），分别执行select sleep(3600) from sbtest.sbtest1语句，然后在第三个连接上 kill 掉 Session 2 的查询：

Session 1：
mysql> select sleep(3600) from sbtest.sbtest1;

Session 2：
mysql> select sleep(3600) from sbtest.sbtest1;
ERROR 2013 (HY000): Lost connection to MySQL server during query
mysql>

Session 3：
mysql> show processlist;
+----+------+--------------------+------+---------+------+--------------+----------------------------------------+
| Id | User | Host               | db   | Command | Time | State        | Info                                   |
+----+------+--------------------+------+---------+------+--------------+----------------------------------------+
| 44 | root | 172.16.64.10:39290 | NULL | Query   |   17 | User sleep   | select sleep(3600) from sbtest.sbtest1 |
| 45 | root | 172.16.64.10:39292 | NULL | Query   |    0 | starting     | show processlist                       |
| 46 | root | 172.16.64.10:39294 | NULL | Query   |    5 | Sending data | select sleep(3600) from sbtest.sbtest1 |
+----+------+--------------------+------+---------+------+--------------+----------------------------------------+
3 rows in set (0.00 sec)

mysql> kill 46;
Query OK, 0 rows affected (0.00 sec)

mysql> show processlist;
+----+------+--------------------+------+---------+------+--------------+----------------------------------------+
| Id | User | Host               | db   | Command | Time | State        | Info                                   |
+----+------+--------------------+------+---------+------+--------------+----------------------------------------+
| 44 | root | 172.16.64.10:39290 | NULL | Query   |   26 | User sleep   | select sleep(3600) from sbtest.sbtest1 |
| 45 | root | 172.16.64.10:39292 | NULL | Query   |    0 | starting     | show processlist                       |
| 46 | root | 172.16.64.10:39294 | NULL | Killed  |   14 | Sending data | select sleep(3600) from sbtest.sbtest1 |
+----+------+--------------------+------+---------+------+--------------+----------------------------------------+
3 rows in set (0.00 sec)

mysql>

可以看到，kill 命令执行之后，Session 2 的连接马上就断开了，但是 Session 2 发起的查询仍旧残留在 MySQL 中。当然，如果是因为innodb_thread_concurrency这个参数导致了类似的问题的话，直接使用set global的命令调高上限，或者直接设置为 0 就可以解决，这个参数的变更是实时对所有连接生效的。

总结一下

MySQL 的 kill 操作并不是想象中的直接强行终止数据库连接，只是发送了一个终止的信号，如果 SQL 自身的执行效率过慢，或者受到其他的因素影响（服务器负载高，触发大量数据回滚）的话，那么这个 kill 的操作很有可能并不能及时终止这些问题查询，反而可能会因为程序侧连接被断开之后触发重连，产生更多的低效查询，进一步拖垮数据库。

以上就是MySQL kill不掉线程的原因的详细内容，更多关于MySQL kill线程的资料请关注脚本之家其它相关文章！

您可能感兴趣的文章:

相关文章

  • MySQL 5.7新特性介绍

    MySQL 5.7新特性介绍

    这篇文章主要为大家详细介绍了MySQL 5.7新特性，了解一下MySQL 5.7的部分新功能，需要的朋友可以参考下
    2016-06-06
  • mysql中主键索引和联合索引的原理与区别

    mysql中主键索引和联合索引的原理与区别

    索引是帮助MySQL高效获取数据的数据结构,本文主要介绍了mysql中主键索引和联合索引的原理与区别,具有一定的参考价值,感兴趣的可以了解一下
    2024-04-04
  • MySQL 全文检索的使用示例

    MySQL 全文检索的使用示例

    全文检索是指计算机索引程序通过扫描文章中的每一个词，对每一个词建立一个索引，指明该词在文章中出现的次数和位置，当用户查询时，检索程序就根据事先建立的索引进行查找，并将查找的结果反馈给用户的检索方式。这个过程类似于通过字典中的检索字表查字的过程。
    2021-06-06
  • MySQL是如何实现主备同步

    MySQL是如何实现主备同步

    这篇文章主要介绍了MySQL是如何实现主备同步的，帮助大家更好的理解和使用MySQL数据库，感兴趣的朋友可以了解下
    2020-12-12
  • MySQL利用procedure analyse()函数优化表结构

    MySQL利用procedure analyse()函数优化表结构

    不知道是否遇到过为MySQL表结构该选择什么类型字段而郁闷？或者为MySQL字段该选择多少长度而纠结？下面这篇文章就给大家介绍一个武林秘籍吧~也是我最近才学来的，感兴趣的朋友们下面来一起看看吧。
    2016-12-12
  • mysql开启binlog步骤讲解

    mysql开启binlog步骤讲解

    在本文里我们给大家分享了关于mysql开启binlog的方法和相关知识点，对此有需要的朋友们跟着学习下。
    2019-03-03
  • 关于MySQL索引的几点值得注意的事项

    关于MySQL索引的几点值得注意的事项

    索引对查询的速度有着至关重要的影响，MySQL索引的建立对于MySQL的高效运行是很重要的
    2014-07-07
  • 基于mysql 5.5 设置字符集问题的详解

    基于mysql 5.5 设置字符集问题的详解

    本篇文章是对关于mysql 5.5设置字符集的问题进行了详细的分析介绍，需要的朋友参考下
    2013-06-06
  • SQL语句之如何用JOIN连接多个表

    SQL语句之如何用JOIN连接多个表

    这篇文章主要介绍了SQL语句之如何用JOIN连接多个表，具有很好的参考价值，希望对大家有所帮助。如有错误或未考虑完全的地方，望不吝赐教
    2022-12-12
  • MySQL索引的各种类型

    MySQL索引的各种类型

    这篇文章主要介绍了MySQL索引的各种类型，帮助大家更好的理解和学习MySQL索引，感兴趣的朋友可以了解下
    2020-09-09

最新评论