专栏首页腾讯云数据库专家服务MySQL 案例:为什么 kill 不掉线程
原创

MySQL 案例:为什么 kill 不掉线程

背景

在日常的使用过程中,时不时会遇到个别,或者大量的连接堆积在 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 的操作很有可能并不能及时终止这些问题查询,反而可能会因为程序侧连接被断开之后触发重连,产生更多的低效查询,进一步拖垮数据库

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • MySQL为什么还有kill不掉的语句?

    在 MySQL 中有两个 kill 命令:一个是 kill query + 线程 id,表示终止这个线程中正在执行的语句;一个是 kill connection...

    码农架构
  • 为什么我的进程被kill掉了

    这段代码非常简单,就是先用mmap的方式,为该进程分配10GiB的虚拟内存,然后再用page写的方式,让操作系统为这10GiB虚拟内存,分配对应的物理内存,最后...

    KINGYT
  • 为什么我的进程被kill掉了

    这段代码非常简单,就是先用mmap的方式,为该进程分配10GiB的虚拟内存,然后再用page写的方式,让操作系统为这10GiB虚拟内存,分配对应的物理内存,最后...

    Linux阅码场
  • 32 | kill不掉的语句

    其实大多数情况下,kill query/connection 命令是有效的。比如,执行一个查询的过程中,发现执行时间太久,要放弃继续查询,这时我们就可以用 ki...

    HaC
  • MYSQL vs JAVA 连接错误

    最近开发告诉我,他们在测试系统的时候,会经常有连接MYSQL的连接被踢掉。具体给我的解释是,JAVA的缓冲池连接MYSQL 保持连接,但再次使用的时候,报连接错...

    AustinDatabases
  • 【MySQL】IO thread和SQL thread的双Yes假象的问题

    ② kill -9 mysqld 或者 reboot 服务器 结果状态:有可能同①,也有可能是双Yes(我自己测试的是同①结果,看别人测的有的是双yes)

    用户5522200
  • 在 MySQL 5.7下排查内存泄露和 OOM 问题全过程

    我的个人网站后台使用的是 MySQL 5.7 版本,前段时间经常被oom-kill,借助5.7的新特性,经过一番排查,终于抓到这只鬼。

    叶金荣
  • 一周碎碎念,2021.7.18

    这周GreatSQL 8.0.25(基于Percona 8.0.25)二进制版发布了,主要忙着准备ansible安装包和Docker镜像的事,也已经分别发布到g...

    老叶茶馆
  • 故障分析 | 记一次 MySQL 复制故障 -Error_code:1317

    爱可生 DBA 团队成员,主要负责 MySQL 故障处理和 SQL 审核优化。对技术执着,为客户负责。

    爱可生开源社区
  • Mysql thread 与 OS thread

    本文作为 Mysql插入2.6亿条垃圾数据后会发生什么? 、手工重现Mysql插入的”2.6亿”垃圾数据 的续篇,初始目的是想看看kill掉执行中的事务对应的o...

    码代码的陈同学
  • 请不要用SECONDS_BEHIND_MASTER来衡量MYSQL主备的延迟时间

    MySQL 本身通过 show slave status 提供了 Seconds_Behind_Master ,用于衡量主备之间的复制延迟,但是今天碰到了一个场...

    小小科
  • MySQL中的kill命令,你用过吗?

    先来说说这俩语法的概念,第一种kill query pid指的是断开当前线程中正在执行的语句,而不断开线程连接。第二种kill pid的方法指的是断开该线程的连...

    AsiaYe
  • Mysql 异常:Lock wait timeout exceeded; try restarting transaction的解决办法

      接口响应时间超长,耗时几十秒才返回错误提示,后台日志中出现Lock wait timeout exceeded; try restarting transa...

    chenchenchen
  • 开学前看的别人的面经笔记

    自我介绍 根据结点求二叉树高度 快排最差的时间复杂度,快排的空间复杂度 快排稳定吗 堆排序 算法题:一圈猴子选大王 4g大文件,64m 内存,找到出...

    韩旭051
  • MySQL中insert语句没有响应的问题分析(r11笔记第21天)

    今天开发的一个同学问我一个MySQL的问题,说在测试数据库中执行一条Insert语句之后很久没有响应。我一看语句是一个很常规的insert into xxx ...

    jeanron100
  • 第18问:MySQL CPU 高了,怎么办?

    我的 MySQL CPU 高了,看了一下 processlist,实在有太多行了,我要不要准备辞职?

    爱可生开源社区
  • 学会用 Mysql show processlist 排查问题

    每次执行看到的结果应该都有变化,因为是实时的,所以我定义为:“事发现场”,每次执行就相当于现场的快照

    码农编程进阶笔记
  • MySQL 案例:analyze,慢查询,与查询无响应

    有时候,遇到同样的 SQL 语句在正式环境的主库和只读实例的执行时间相距甚远时,第一时间就会想到是不是采样信息不一致,导致执行计划不准,从一个高效的查询变成了慢...

    王文安@DBA
  • 一次Mariadb死锁排查过程回顾

    访问了几个页面都是正常的,唯独某几个页面查询实时监控数据时无法加载出来,F12查看接口发现有几个业务相似的接口长时间不返回数据。

    机智的程序员小熊

扫码关注云+社区

领取腾讯云代金券