L1ngg's Home

1. 网络层面的事实：TCP FIN 仅停留在内核缓冲区#

当客户端决定放弃连接并调用销毁方法时，操作系统的传输层向 MySQL 服务器发送了一个 TCP FIN 数据包。

服务端宿主机的 Linux 内核网络栈在收到 FIN 包后，严格按照 TCP 状态机流转：

• 内核向客户端回复 ACK。
• 将对应的 Socket 文件描述符状态流转至 CLOSE_WAIT。
• 内核在 Socket 接收缓冲区中追加一个 EOF 标记。

然而，这一切仅仅发生在内核空间（Kernel Space）内。 操作系统绝对不会主动发送信号打断正在用户空间执行业务逻辑的普通应用程序线程。

2. MySQL Worker 线程的物理盲区：只顾埋头计算，从不看网卡#

MySQL 为每个连接分配专门的工作线程（One-Thread-Per-Connection 经典模型，即使在线程池插件下执行态亦是单线程执行）。

当 Worker 线程正在执行一条耗时 SQL 时，它的代码指针正在深陷于存储引擎内部（例如 InnoDB 的 B+ 树叶子节点遍历、Buffer Pool 页检索、临时表构建或 CPU 内存排序）：

• 此时线程正在拼命执行计算指令，它根本没有调用 read()、recv() 或 epoll_wait() 去读取网卡数据。
• 它完全不知道操作系统内核的 Socket 接收缓冲区里已经躺着一个 EOF。
• 只有当整条 SQL 完全执行结束，线程整理好数据行准备通过网络推回给客户端、执行 write() / send() 系统调用时，操作系统内核才会抛出 EPIPE或 ECONNRESET（Connection reset by peer）错误。

结论：在 SQL 运行期间，客户端单方面挂断电话，服务端只要不去看屏幕，就根本不知道对面已经挂断。MySQL 依然会耗尽所有 CPU 和 I/O 配额，计算一份注定被丢弃的结果。

1. 单进程多线程模型决定了无法使用“抢占式强杀”#

在 Linux 操作系统中，若要强行抹掉一个进程，发送 SIGKILL（即 kill -9）会让操作系统内核直接回收该进程的虚拟内存空间和文件描述符，属于典型的抢占式中断。

但 MySQL 是一个单进程多线程架构。 所有连接的线程都共享同一个进程空间、内存堆、缓冲池和各种全局互斥锁。如果允许外部粗暴地强杀某个线程的 CPU 执行指针：

• 线程可能正持有 lru_list_mutex 或某个数据页的读写锁。
• 突然暴毙会导致全局锁永远无法释放，数据结构处于半更新状态，进而引发整库内存损坏与整个 mysqld 实例 Crash 崩溃。

因此，MySQL 绝不能、也无法实现抢占式的线程强杀，它必须采用“协作式中断”。

2. 源码底层的真相：仅仅是内存里打了个标记#

在 MySQL 源码中，每个客户端连接由一个 THDC++ 对象承载。当执行 KILL QUERY <id> 时，MySQL 实际执行的核心逻辑极为轻量：

1
// 伪代码：MySQL 处理 KILL QUERY 的核心实现逻辑
2
THD *target_thd = Global_THD_Manager::get_instance()->find_thd(target_thread_id);
3
if (target_thd != nullptr) {
4
    // 仅仅是修改内存结构体里的枚举标记
5
    target_thd->awake(THD::KILL_QUERY);
6
}

进入 awake() 方法内部，其核心本质就是原子操作赋值：

1
void THD::awake(killed_state state_to_set) {
2
    this->killed = state_to_set; // 设置内存标志位: THD::KILL_QUERY
3
    ...
4
    // 若当前线程陷入了条件变量等待，则尝试唤醒它
5
    mysql_mutex_lock(&this->LOCK_thd_data);
6
    if (this->current_mutex) {
7
        mysql_cond_broadcast(this->current_cond);
8
    }
9
    mysql_mutex_unlock(&this->LOCK_thd_data);
10
}

下发 KILL QUERY 的瞬间，目标线程的 CPU 执行指针根本不会停下来，它只是在内存元数据里被盖上了一个“你已经被标记为死亡”的戳。

3. 被杀线程的自杀逻辑：检查点（Checkpoints）#

目标 Worker 线程必须在自己的代码执行主流程中，主动、定期地去调用 thd->is_killed() 检查这个标记：

1
// 在存储引擎或 SQL 解析执行引擎的关键内层循环中
2
while (has_more_records) {
3
    // 关键自检点：自愿检查自身生命状态
4
    if (thd->is_killed()) {
5
        clean_up_temporary_tables();
6
        clean_up_allocated_memory();
7
        return ER_QUERY_INTERRUPTED; // 主动抛错退出
8
    }
9

10
    // 继续读取并处理下一行物理数据
11
    fetch_next_row();
12
}

4. 为什么 SLEEP 能秒停，而复杂查询往往“杀不掉”？#

理解了检查点机制，许多长期困扰工程师的现象就有了清晰的解释：

• 为什么 SELECT SLEEP(100) 能被迅速杀掉？ SLEEP() 的物理底层调用了操作系统的条件变量定时等待（pthread_cond_timedwait）。当执行 awake() 时，MySQL 会广播信号（mysql_cond_broadcast）唤醒该条件变量。线程被提前唤醒后，立刻触发了后续的 is_killed() 检查，因而能迅速自杀退出。
• 为什么大查询、复杂计算经常停留在 State: Killed 杀不掉？ 若查询陷入了没有设置检查点的执行盲区，线程代码指针根本走不到 thd->is_killed() 这行代码：
  1. 底层物理阻塞 I/O：线程陷入了操作系统的同步阻塞调用，例如大事务触发的磁盘脏页强刷（fsync），CPU 处于内核态等待，根本无法回用户态自检；
  2. 等待行锁（Lock Wait）：线程正挂在 InnoDB 的事务锁等待队列中，被挂起沉睡，在锁等待超时或被锁持有者唤醒前，不会进入执行检查；
  3. 复杂排序（External Sort）与哈希聚合：部分旧版本代码在极深层的数据结构内部排序时，检查点稀疏，必须等一批数据块处理完成才做一次检查。

1. 两者底层行为的本质差异#

2. 致命场景剖析：锁死整个业务链路的“幽灵事务”#

假设某业务系统正在执行一段典型的扣款事务：

1
-- 业务代码伪代码
2
BEGIN;
3
-- 第一步：执行更新，成功锁定了 id=1 的用户记录（获取排他 X 锁）
4
UPDATE account SET balance = balance - 100 WHERE id = 1;
5

6
-- 第二步：执行一个复杂的风控校验查询，包含耗时的跨表关联与大范围扫描
7
SELECT * FROM risk_records WHERE account_id = 1 FOR UPDATE;

如果在第二步 SELECT ... FOR UPDATE 执行过程中触发了客户端超时，运维或自动化调度器下发了：

1
KILL QUERY <thread_id>;

底层发生的物理事实是：

1. 第二步的 SELECT 语句收到软中断后自杀退出，向客户端返回了错误代码：ER_QUERY_INTERRUPTED。
2. 此时，这个客户端连接的事务并没有结束！连接仍然活着，事务依然处于未提交（Uncommitted）且未回滚的状态。
3. 第一步 UPDATE 锁定的 id=1 行级排他锁（X-Lock），依然牢牢握在该事务手中！

除非客户端感知到异常后主动补发一条 ROLLBACK，或者该连接后续被彻底销毁（触发连接关闭级回滚），否则只要该连接空闲挂在连接池中，其他任何试图访问或修改 id=1 的业务并发请求，都会陷入漫长的锁等待队列，直到触发 Lock wait timeout exceeded 批量阵亡。

这就解释了为什么生产环境下单方面使用 KILL QUERY 经常不但无法平息故障，反而引发了大面积的级联死锁和次生雪崩。

1. InnoDB MVCC 与 Undo Log 的物理回滚机制#

在 InnoDB 存储引擎中，数据的一致性与事务原子性依赖 Undo Log 保证：

• 写入是顺序与内存加速的：执行 INSERT/UPDATE/DELETE 时，修改先落在 Buffer Pool 内存页中，并追加写入顺序的 Redo Log（WAL 机制），效率极高。
• 回滚是昂贵的随机反向修正：当一个运行了数分钟的大事务被强杀并触发回滚时，InnoDB 必须保障 ACID 的原子性。后台回滚线程必须遍历该事务产生的所有 Undo Log 链条，逐行执行逆向补偿操作（例如将删掉的行重新插回、把更新掉的字段重新写回旧值）。

1
写入过程: 内存加速 + 顺序 Redo Log 追加 (快)
2
                   ↓↓↓
3
回滚过程: 逆向解析 Undo Log 链 + 大量离散的数据页查找 + 随机覆写 (极慢且消耗 I/O)

2. 为什么强制 KILL 会导致数据库“假死”？#

假设一个写入事务在被强杀前已经更新了 100 万行数据：

1. 反向随机 I/O 爆炸：回滚这 100 万行需要将大量已经被刷新到磁盘或冷出的数据页重新加载进内存，执行物理修改。回滚耗费的 I/O 资源通常是最初写入操作的数倍。
2. Buffer Pool 严重污染：海量回滚操作会把活跃的缓存热点数据挤出 Buffer Pool，导致常规线上业务的缓存命中率暴跌。
3. 磁盘 I/O 打满至 100%：在高负载压测或故障恢复期，强杀大连接引发的海量回滚会瞬间将底层存储（SSD / 云盘）的 IOPS 和吞吐量打满，导致整个 MySQL 实例无法响应任何读写请求。

物理铁律：永远不要低估回滚的代价。对于已经产生大规模物理写操作的长事务，强杀不是“免费的取消”，它只是将性能债以更激烈的随机 I/O 形式提前兑现。

1. 进程模型带来的天然硬中断优势：OS SIGINT#

• MySQL 的妥协（单进程多线程）：由于整个实例运行在同一个进程空间中，MySQL 绝不能对线程使用 OS 信号中断，否则会导致全局内存崩溃，因此只能依赖温和、迟钝的“软标记轮询”。
• PostgreSQL 的硬核设计（多进程模型）：
  • 每个客户端连接对应一个独立的 Linux 操作系统进程（Backend Process）。
  • 当需要取消正在运行的查询时，PostgreSQL 的管理进程可以直接向目标后端进程发送操作系统原生的 SIGINT 信号！
  • Linux 内核会立刻打断该进程当前正在执行的用户态 CPU 指针，强行切入预先注册的信号处理函数（Signal Handler）。
  • 信号处理函数将错误标记置位，并在退栈时快速抛出 canceling statement due to user request 异常。响应极为迅速，几乎不存在 MySQL 那种“卡在深层计算杀不掉”的顽疾。

2. 覆盖所有语句的原生超时机制：statement_timeout#

在 MySQL 5.7 之前，服务端根本没有原生语句超时机制。5.7 引入的 max_execution_time 至今仅支持只读 SELECT 语句，对 INSERT/UPDATE/DELETE 完全无效。所有业务驱动为了实现写超时，不得不各自在客户端起定时器、建新连接发 KILL，将复杂度全面转嫁给调用方。

而在 PostgreSQL 中，语句级超时从底层就得到了全量支持：

1
-- 设置当前会话或事务的单条语句最大执行时间为 3 秒
2
SET statement_timeout = '3000';

无论是复杂的分析型 SELECT，还是涉及千万行变更的 UPDATE 或 DELETE，底层内核定时器一旦到期，立刻触发中断并回滚语句，完全不需要客户端外挂任何旁路线程发 KILL。

3. 主动探知网络断开：client_connection_check_interval#

针对“客户端超时挂断，服务端当睁眼瞎傻跑”的世纪难题，PostgreSQL 在 14 版本中引入了极具前瞻性的参数：

1
# 在执行长查询期间，定期检测客户端连接健康状况（单位：毫秒）
2
client_connection_check_interval = 500

• 开启后，Backend 进程在执行耗时查询的间隙，会主动使用操作系统极其廉价的 poll() 系统调用探查 Socket 状态。
• 一旦检测到客户端已断开（收到 TCP FIN 或 RST），PgSQL 会立刻自我终止查询，释放所有持有的行锁并回滚事务！ 绝不浪费一秒 CPU 算力在没人接收的废弃计算上。

4. 协议级别的带外取消通道（Out-of-Band CancelKey）#

在 MySQL 中，如果线上发生雪崩，连接池已满，你想发一个 KILL 123，你必须建立一个全新的 TCP 连接并走完三次握手、用户名密码密码鉴权、权限校验等一系列繁重流程。在数据库高负载时，这个 KILL 请求往往根本连不上去，造成“想杀慢查询救火，却因连接已满无法杀”的死锁怪圈。

PostgreSQL 在通信协议设计之初就考虑到了这一场景：

• 建连握手时下发密钥：客户端建连成功后，Postmaster 进程会随认证响应一同下发两个 32 位整数：BackendPid 与 CancelKey。
• 免鉴权轻量取消包：当需要取消该连接的查询时，客户端只需打开一个微型的临时 Socket，发送一个仅有几十字节的“取消请求包”（包含 BackendPid 与 CancelKey），无需执行用户名密码鉴权，无需分配复杂的 Session 状态。
• Postmaster 验证密钥无误后，直接向对应 Pid 发送 SIGINT。这种机制即便在系统高压、连接池爆满的情况下，依然能以极小代价实施紧急制动。

5. 语义清晰的事务 Aborted 状态与锁释放#

在 PostgreSQL 中，一旦查询被中断或超时：

• 整个事务立刻进入 Aborted 错误状态（该事务内后续所有语句都会被直接拦截拒绝：current transaction is aborted, commands ignored until end of transaction block）。
• 事务持有的所有行锁和表锁在事务回滚退出后被迅速且干净地释放，绝不会像 MySQL 那样将事务锁挂起在活跃连接中、任由其毒化整个系统。

1. 客户端设计：践行“快速自保（Fast-Fail）”，放弃完美治理幻想#

很多系统之所以在超时后发生雪崩，核心原因在于客户端试图在主请求链路中同步等待 KILL 成功。

• 快速断路（Fast-Fail）：当客户端触发业务超时时，应立即放弃当前阻塞的 Socket 连接，将错误反馈给调用方或触发降级策略，严禁在主流程中同步等待数据库 KILL 的响应。
• 异步尽力而为（Best-effort KILL）：
  • 如果一定要在客户端触发 KILL，应将其移入独立的低优先级异步任务队列。
  • 异步下发 KILL CONNECTION（优先杀连接而非杀查询，逼迫事务回滚）；
  • 设置严格的兜底阈值：若异步 KILL 超过 500ms 未响应，应直接放弃该任务，记录告警日志，防止辅助治理连接将连接池打满。
• 连接池熔断与重建：针对超时的物理连接，直接调用底层 destroy() 将其物理关闭并从连接池中剔除，由连接池按需冷启动补齐连接，切勿将一个状态未知的连接直接归还连接池复用。

2. MySQL 服务端防护与参数加固#

如果业务技术栈无法脱离 MySQL，必须从参数和架构层面建立防御纵深：

• 只读查询开启服务端硬限：在只读从库或慢查询代理层全局配置 max_execution_time（例如设置 SET GLOBAL max_execution_time = 5000），让只读大查询在服务端自绝，杜绝慢查堆积。
• 收紧锁等待超时：将 innodb_lock_wait_timeout 从默认高风险的 50 秒大幅缩减至合理区间（例如 3~5 秒）。当某个事务因超时未释放锁时，排队的其他业务会迅速失败返回，防止整库线程队列被打满。
• 杜绝长事务与大批量写操作：
  • 单次批量插入、更新或删除必须严格拆解为微批次（Batching，例如每次处理 500~1000 行并主动 Commit）；
  • 缩小事务生命周期，杜绝将 RPC 远程调用、HTTP 请求或耗时业务计算包裹在数据库事务中。

3. 技术选型思考：何时应该果断迁移至 PostgreSQL？#

如果系统具备以下特征，从架构根源上评估迁移至 PostgreSQL 往往能获得巨大的可靠性红利：

1. 多租户与复杂报表混跑：对单查询耗时敏感，需要绝对可靠的 statement_timeout 熔断保障，杜绝客户端黑科技打补丁；
2. 高频短超时与微服务链条：上游网关超时阈值极短（如 1~2 秒），需要数据库能主动感知客户端断开并立刻释放行锁，避免级联雪崩；
3. 极度痛恨次生锁冲突：经常因为长事务异常、客户端断开未提交、慢查治理不善导致生产大面积锁超时。