MySQL如何通过命令程序化终止正在执行的存储过程

存储过程不会作为独立进程出现在information_schema.processlist中，它的执行完全依附于发起调用的数据库会话线程，终止存储过程的本质是终止承载它执行的对应会话上的查询/连接。你之前的查询找不到目标记录，核心问题是筛选逻辑过于宽泛，没有匹配存储过程执行时的会话特征，甚至可能把当前执行查询的会话本身也纳入结果集，无法定位到目标线程。

定位目标执行线程的正确写法 #

不要使用全量匹配非系统用户的粗粒度查询，通过多维度条件精准筛选正在执行目标存储过程的线程ID，参考SQL如下：

SELECT 
  id,
  user,
  host,
  db,
  command,
  time,
  state,
  info
FROM information_schema.processlist
WHERE 
  -- 排除当前执行这条查询的会话，避免误杀自己
  id != CONNECTION_ID()
  -- 存储过程执行时，对应会话的command字段通常为Query状态
  AND command = 'Query'
  -- 可指定存储过程所在的业务库缩小查询范围
  -- AND db = '你的业务库名'
  -- 可结合存储过程名称、调用方IP、执行时长等特征进一步过滤
  -- AND host LIKE 'Java服务IP%'
  -- AND time > 允许的最大执行时长阈值
  -- AND info LIKE '%CALL 你的目标存储过程名%'
;

注意：如果存储过程内部包含多段长耗时SQL，info字段不会一直显示CALL 存储过程名()的语句，会实时显示当前正在执行的内部SQL片段，定位时可以结合执行账号、来源IP、已执行时长几个维度联合判断，避免误杀。

终止存储过程的操作 #

拿到目标线程的id后，根据需求选择对应命令：

• 仅终止存储过程执行、保留数据库连接用于后续复用，执行：KILL QUERY 目标线程ID;
• 直接断开异常会话、同时终止存储过程执行，执行：KILL 目标线程ID;

命令执行后，存储过程中已经执行但未提交的事务会自动回滚，不会产生脏数据；调用存储过程的客户端（比如你的Java程序）会收到Query execution was interrupted的异常，直接在业务代码中捕获处理即可。

Java API集成的注意事项 #

• 禁止使用你之前拼接全量KILL语句的逻辑，这类写法极易误杀线上正常业务连接，必须先通过多维度条件精准筛选出目标线程ID，再单独执行KILL命令
• Java服务使用的数据库账号需要授予PROCESS权限和CONNECTION_ADMIN权限（MySQL 8.0之前版本为SUPER权限），否则无法查询processlist全量数据、也无权终止其他会话
• 最稳妥的线程标记方案：Java端发起存储过程调用前，先在当前连接执行SET @biz_request_id = '业务唯一请求标识';，后续定位线程时直接匹配info字段中包含该唯一标识的记录即可，零误杀风险
• 不要尝试在存储过程内部编写自终止逻辑，存储过程执行时是单线程顺序执行的，无法响应内部触发的终止信号，必须通过外部会话发起KILL操作

本地测试的小提示 #

在MySQL Workbench中测试时，Workbench会为每个查询标签页维护独立的数据库连接，查processlist时可以通过host字段的端口号区分不同标签页的连接，不要误杀其他标签页的正常查询。

内容的提问来源于stack exchange，提问作者AGaur