MySQL 客户端 Ctrl + C，服务端会发生什么？

csch

发布于 2023-05-24 10:16:31

5740

发布于 2023-05-24 10:16:31

文章被收录于专栏：一树一溪一树一溪

我们也许有过这样的经历：用 mysql 客户端连上数据库，执行一条 SQL，结果迟迟执行不完，我们等得不耐烦了，顺手就是一个 Ctrl + C。

Ctrl + C 之后，客户端会干什么，服务端又会发生什么？我们一起来看看。

本文内容基于 MySQL 8.0.32 源码，涉及存储引擎为 InnoDB。

正文

1. 客户端会干什么？

想要观察 Ctrl + C 时，客户端会干什么，用 mysql 连接数据库时可以指定 -v 参数，如下：

mysql -h127.0.0.1 -uroot -v

连上数据库之后，执行一条 SQL（以 UPDATE 为例）。SQL 执行完成之前，在键盘上按下 Ctrl + C，如下：

注意：没有使用 begin 显式开启事务，且系统变量 autocommit 的值为 ON。

mysql> UPDATE t1 SET blob1 = REPEAT("这是 blob2 字段", 10240);
--------------
UPDATE t1 SET blob1 = REPEAT("这是 blob2 字段", 10240)
--------------

-- 客户端发送 KILL QUERY 给服务端之后
-- 输出的提示信息
^C^C -- sending "KILL QUERY 11" to server ...

# 服务端执行 KILL QUERY 之后
# 客户端自己的输出信息
^C -- query aborted

-- 服务端返回给客户端的信息
ERROR 1317 (70100): Query execution was interrupted

从以上输出可以看到，客户端 Ctrl + C，实际上是给服务端发出了一条 KILL QUERY 命令。

这和我们手动执行 KILL QUERY 命令是一样的，接下来，我们就来看看服务端是怎么执行 KILL QUERY 命令的。

2. KILL QUERY

在 KILL QUERY 命令之前，客户端已经发出了一条 Update SQL，服务端分配了一个线程，正在执行 Update SQL。

Update SQL 还没执行完，客户端 Ctrl + C 又发出了 KILL QUERY 命令，服务端收到命令之后，会调度另一个线程来执行 KILL QUERY 命令。

为了方便介绍，我们把执行 Update SQL 的线程称为 Update 线程，执行 KILL QUERY 命令的线程称为 Kill 线程。注意：MySQL 内部是不做这样区分的。

KILL QUERY 命令的执行流程如下：

第 1 步，Kill 线程根据 query id 查找 Update 线程。如果没有找到，KILL QUERY 命令执行结束；如果找到了，进入第 2 步。

query id 是 show processlist 执行结果中的 id 字段。

第 2 步，Kill 线程判断当前连接的 MySQL 用户是否有权限干掉 Update 线程。如果没有权限，KILL QUERY 命令执行结束；如果有权限，进入第 3 步。

第 3 步，判断 Update 线程是否正在读写数据字典表。

如果不是，Kill 线程继续执行第 4 ~ 6 步；如果是，Kill 线程的使命就到此结束了，接力棒交给 Update 线程。

Update 线程读写数据字典表结束，就会马上开始执行 KILL QUERY 命令的第 3 ~ 6 步。

这种情况下，第 3 步会被执行 2 次（Kill 线程和 Update 线程各执行一次）。

第 4 步，把 Update 线程的 killed 属性设置为 KILL_QUERY，此时，Update 线程处于被标记为将要被干掉，但是还没有被干掉的状态。

这一步可以想象成城市建设过程中，在要拆迁的房子上写了个大大的拆字，但是房子还立在那里。

第 5 步，如果 Update 线程正在等待获取存储引擎中的锁，则放弃等待；如果 Update 线程已经持有存储引擎中的锁，则释放锁。

第 6 步，判断 Update 线程是否持有某个条件变量（保存在 current_cond）中。

如果持有，发送广播通知正在等待这个条件变量的其它线程，告诉它们可以继续执行了。

通过前面的介绍，我们可以看到：不管是 Kill 线程，还是 Update 线程自己执行第 3 ~ 6 步，都只是给 Update 线程打上了 KILL_QUERY 标记，而没有直接把 Update 线程干掉。

Update 线程是怎么被干掉的呢？请继续往下看。

3. 自己把自己干掉

KILL QUERY 执行过程中，为什么不直接把 Update 线程干掉？

不是不想，而是不能。

因为线程不管执行什么操作，都需要进行收尾工作，做到有始有终。

如果 Update 线程直接被干掉，就来不及进行收尾工作，例如：已经申请的内存无法释放，会导致内存泄漏。

所以，想要妥善干掉一个线程，需要即将被干掉的线程主动配合 Kill 线程才行。

妥善干掉一个 Update 线程的场景是这样的：

Kill 线程对 Update 线程说：我要把你干掉。

Update 线程回答：不劳你动手，我自己来。

MySQL 让这个场景变成现实的方式，是在代码中的各个角落进行埋点，埋点逻辑：判断当前线程是否被打上了 KILL_QUERY 标记，如果是，则中断正在执行的操作，进入收尾阶段。

举个例子：

// sql/sql_update.cc
// 以下代码处理更新单表的 SQL，例如：
// update t1 set i1 = 100
bool Sql_cmd_update::update_single_table(THD *thd) {
  ...
  while (true) {
    // 从存储引擎读取一条记录
    error = iterator->Read();
    // 如果读取出错（error）
    // 或者 thd->killed 不等于 0（也就是 true）
    // 对应本文的场景是：线程被打上了 KILL_QUERY 标记
    // 直接结束循环
    if (error || thd->killed) break;
    ...
  }
  ...
}

从以上代码可以看到，执行 Update 操作过程中，如果发现读取出错（对应本文场景是 Update 线程被打上了 KILL_QUERY 标记），直接 break 退出循环，中断执行。

4. 回滚

Update 线程执行过程中，事务有可能已经增、删、改了一些数据，中断正在执行的操作之后，事务是需要回滚的。

当 Update 线程的执行流程回到 mysql_execute_command()：

int mysql_execute_command(THD *thd, bool first_level) {
  ...
  if ((thd->is_error() && !early_error_on_rep_command) ||
      (thd->variables.option_bits & OPTION_MASTER_SQL_ERROR))
    trans_/opt/data/workspace_c/mysql8/sql/sql_class.ccrollback_stmt(thd);
  else {
    /* If commit fails, we should be able to reset the OK status. */
    thd->get_stmt_da()->set_overwrite_status(true);
    trans_commit_stmt(thd);
    thd->get_stmt_da()->set_overwrite_status(false);
  }
  ...
}

从代码中可以看到，thd->is_error() 返回 true，说明事务执行过程中出现了错误，对应到本文的场景，就是事务被 KILL QUERY 中断了，会执行 trans_rollback_stmt(thd)，回滚事务。