17370845950

SQL执行中断分超时自动终止和手动KILL干预两类：前者通过max_execution_time设置毫秒级阈值，触发thd_killed()轮询检查并协作中止；后者分KILL QUERY（仅停语句）与KILL CONNECTION（断连），均依赖线程主动检测killed标志，故I/O或锁等待时可能延迟生效。

SQL执行中断，核心就两点：超时自动终止，和手动kill干预。它们不是简单“断开连接”，而是通过数据库内部机制触发中止逻辑，关键在于线程状态标记与执行点轮询。

超时控制靠 max_execution_time

这是最稳妥的预防手段，作用于单条语句级别：

• 在执行 SQL 前设置：SET SESSION max_execution_time = 5000;（单位毫秒）
• 超时后，MySQL 自动给当前线程打上 killed 标志，后续每次执行块（如读取一批行、完成一次排序阶段）都会调用 thd_killed() 检查；一旦为真，立即停止、清理临时表、回滚事务
• 注意：它只对 SELECT、UPDATE、INSERT ... SELECT 等语句生效，不适用于 DDL（如 ALTER TABLE）或存储过程内嵌逻辑

手动 kill 的两种类型要分清

MySQL 的 KILL 不是暴力杀进程，而是发信号让目标线程协作退出：

• KILL QUERY 123：仅终止线程 123 正在运行的那条 SQL，连接保持，可继续发新语句
• KILL CONNECTION 123（或简写 KILL 123）：先终止当前语句，再断开整个连接，释放会话资源
• 执行后若看到 Command: Killed，说明标志已设，但线程尚未轮询到——比如正卡在磁盘 I/O 或锁等待中，需等它下次检查才能退出

为什么有时 kill 不立刻生效？

根本原因在于“协作式中止”设计：

• 线程必须主动调用 thd_killed() 才能响应，而某些操作（如大事务回滚、InnoDB 行锁等待、FULLTEXT 索引重建）期间不会频繁检查标志
• 如果语句处于 Waiting for table metadata lock 或 Locked 状态，kill 可能要等到锁释放后才真正退出
• 不要用 kill -9 强杀 mysqld 进程，会导致实例异常终止、数据文件损坏风险

快速定位并 kill 慢查询的操作路径

从发现到处理，三步闭环：

• 查活跃会话：SHOW PROCESSLIST; 或更精准地 SELECT ID, USER, HOST, DB, COMMAND, TIME, STATE, INFO FROM INFORMATION_SCHEMA.PROCESSLIST WHERE TIME > 60 AND COMMAND = 'Query';
• 确认目标 ID 后执行：KILL QUERY 12345;
• 再查一遍 processlist，观察 STATE 是否变为 Killed，INFO 是否变为空；若长时间未消失，需结合 INFORMATION_SCHEMA.INNODB_TRX 查是否卡在事务回滚