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查是否卡在事务回滚
