关于数据库:MySQL-kill-会话不起作用

• GreatSQL 社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。
• GreatSQL 是 MySQL 的国产分支版本，应用上与 MySQL 统一。
• 作者：王权贫贱
• 文章起源：GreatSQL 社区原创

背景

在一次日常测试中发现，kill 一个会话后，SQL 语句仍然在运行并没终止；被 kill 的会话从新连贯并继续执行原来的 SQL 语句。

测试

本次测试基于 MySQL 8.0.27

1. 创立测试表

create table t1 (id int, name  varchar(30));   
insert into t1 values (1,'a'),(2,'b');  

2. 开启 3 个会话

session1：开启一个事务不提交

mysql> use test
Database changed
mysql> 
mysql> 
mysql> begin;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from t1;
+------+------+
| id   | name |
+------+------+
|    1 | a    |
|    2 | b    |
+------+------+
2 rows in set (0.00 sec)

session2：执行 DDL 语句

mysql> use test
Database changed
mysql> 
mysql> 
mysql> rename table t1 to t2; 

session3：kill session2

mysql> show processlist;
+-----+------+---------+---------+--------------------------------+----------------------+
| Id  | db   | Command | Time    | State                          | Info                 |
+-----+------+---------+---------+--------------------------------+----------------------+
|   6 | NULL | Daemon  | 4399013 | Waiting on empty queue         | NULL                 |
| 132 | test | Sleep   |     232 |                                | NULL                 |
| 134 | test | Query   |     123 | Waiting for table metadata lock| rename table t1 to t2|
| 135 | test | Query   |       0 | init                           | show processlist     |
+-----+------+---------+---------+--------------------------------+----------------------+
4 rows in set (0.00 sec)

mysql> kill 134;
Query OK, 0 rows affected (0.01 sec)
#为了排版，表格字段略有删减，具体信息请看图片

session2：session2 从新连贯，并且继续执行 DDL 语句，仍处于锁期待状态

mysql> rename table t1 to t2; 
ERROR 2013 (HY000): Lost connection to MySQL server during query
No connection. Trying to reconnect...
Connection id:    136
Current database: test

session3：查看会话信息

mysql> show processlist;
+-----+------+---------+---------+--------------------------------+----------------------+
| Id  | db   | Command | Time    | State                          | Info                 |
+-----+------+---------+---------+--------------------------------+----------------------+
|   6 | NULL | Daemon  | 4399260 | Waiting on empty queue         | NULL                 |
| 132 | test | Sleep   |     479 |                                | NULL                 |
| 135 | test | Query   |       0 | init                           | show processlist     |
| 136 | test | Query   |     193 | Waiting for table metadata lock| rename table t1 to t2|
+-----+------+---------+---------+--------------------------------+----------------------+
4 rows in set (0.00 sec)
#为了排版，表格字段略有删减，具体信息请看图片

能够看到，kill session2 后，session2 从新连贯并且继续执行 SQL

session1：提交事务

mysql> commit;   
Query OK, 0 rows affected (0.01 sec)  

session2：执行胜利

mysql> use test
Database changed
mysql> 
mysql> 
mysql> rename table t1 to t2; 
ERROR 2013 (HY000): Lost connection to MySQL server during query
No connection. Trying to reconnect...
Connection id:    136
Current database: test

Query OK, 0 rows affected (8 min 38.00 sec)

通过上述测试，能够看到明明执行了 kill 命令，然而仍然没有达到咱们想要的成果，仿佛 kill 命令没有失效一样。

通过查问材料发现，因为通过 MySQL 客户端登录，--reconnect 从新连贯选项默认是开启的，该选项在每次连贯失落时都会进行一次从新连贯尝试；因而在 kill session2 后，session2 从新连贯并再次执行之前的 SQL 语句，导致感觉 kill 命令没有失效。

  --reconnect         Reconnect if the connection is lost. Disable with
                      --disable-reconnect. This option is enabled by default.
                      (Defaults to on; use --skip-reconnect to disable.)

解决

能够通过以下 2 种形式防止上述问题的产生：

1. 执行 kill query 命令

KILL QUERY终止连贯以后正在执行的语句，但放弃连贯自身不变

session3：执行 KILL QUERY 命令

mysql> show processlist;
+-----+------+---------+---------+--------------------------------+----------------------+
| Id  | db   | Command | Time    | State                          | Info                 |
+-----+------+---------+---------+--------------------------------+----------------------+
|   6 | NULL | Daemon  | 4401560 | Waiting on empty queue         | NULL                 |
| 132 | test | Sleep   |      11 |                                | NULL                 |
| 135 | test | Query   |       0 | init                           | show processlist     |
| 137 | test | Query   |       3 | Waiting for table metadata lock| rename table t1 to t2|
+-----+------+---------+---------+--------------------------------+----------------------+
4 rows in set (0.00 sec)

mysql> 
mysql> kill query 137;
Query OK, 0 rows affected (0.00 sec)
#为了排版，表格字段略有删减，具体信息请看图片

session2：

mysql> rename table t1 to t2;   
ERROR 1317 (70100): Query execution was interrupted  

能够看到 session2 执行的语句曾经被终止了，达到了咱们想要的成果。

2. 登录 mysql 客户端时加 –skip-reconnect 选项

--skip-reconnect 示意当连贯失落时不会进行从新连贯的尝试

session2：登录时加 --skip-reconnect 选项

shell> mysql -uroot -p -h127.0.0.1  -P3306 --skip-reconnect  

session3：执行 kill 命令

mysql> show processlist;
+-----+------+---------+---------+--------------------------------+----------------------+
| Id  | db   | Command | Time    | State                          | Info                 |
+-----+------+---------+---------+--------------------------------+----------------------+
|   6 | NULL | Daemon  | 4402073 | Waiting on empty queue         | NULL                 |
| 132 | test | Sleep   |     524 |                                | NULL                 |
| 135 | test | Query   |       0 | init                           | show processlist     |
| 139 | test | Query   |       4 | Waiting for table metadata lock| rename table t1 to t2|
+-----+------+---------+---------+--------------------------------+----------------------+
4 rows in set (0.00 sec)

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

session2:

mysql> rename table t1 to t2;
ERROR 2013 (HY000): Lost connection to MySQL server during query

能够看到 session2 的会话连贯曾经被终止，并且没有主动从新连贯，达到了咱们想要的成果。

总结

1. 通过 MySQL 客户端登录时，会话从新连贯的选项 --reconnect 默认是开启的，如果要禁止从新连贯可在登录时增加 –skip-reconnect
2. KILL CONNECTION 与 KILL 雷同，它在终止连贯正在执行的任何语句后，再终止会话连贯。
3. KILL QUERY 终止连贯以后正在执行的语句，但放弃连贯自身不变。

参考链接

https://dev.mysql.com/doc/refman/8.0/en/kill.html

https://dev.mysql.com/doc/refman/8.0/en/mysql-command-options…

Enjoy GreatSQL :)

## 对于 GreatSQL

GreatSQL 是由万里数据库保护的 MySQL 分支，专一于晋升 MGR 可靠性及性能，反对 InnoDB 并行查问个性，是实用于金融级利用的 MySQL 分支版本。

相干链接：GreatSQL 社区 Gitee GitHub Bilibili

GreatSQL 社区：

社区博客有奖征稿详情：https://greatsql.cn/thread-100-1-1.html

技术交换群：

微信：扫码增加 GreatSQL 社区助手 微信好友，发送验证信息 加群。