错误码1317（ER_QUERY_INTERRUPTED）仅在SQL执行阶段触发，非解析阶段；根因包括超时、主动取消或连接中断，常见于JDBC setQueryTimeout、max_execution_time限制（仅对纯SELECT生效）、Workbench策略/会话/基础设施层问题。
这不是解析阶段的错误，而是执行阶段被中断了。 MySQL 里没有“解析阶段报 Query interrupted”这回事——ER_QUERY_INTERRUPTED（错误码 1317，SQLSTATE 70100）只会在语句已通过语法/权限检查、真正开始执行后触发。所谓“一执行就中断”，大概率是超时、主动取消或连接断开导致的假性“瞬间失败”。
为什么 SET GLOBAL max_execution_time=0 不起作用？
这个参数只对 SELECT 语句生效，且不作用于以下场景：
- 存储过程体内的
SELECT（哪怕单独执行也无效） -
INSERT ... SELECT、UPDATE ... WHERE (SELECT ...)这类写操作中的子查询 - mysqldump、MySQL Workbench 的批量脚本执行（它们走的是客户端驱动层控制流，不是 server 端 SQL 执行超时）
- Java 中调用了
Statement.setQueryTimeout()，此时 JDBC 驱动会在客户端侧发起KILL QUERY，优先级高于 server 端max_execution_time
验证方式：SELECT @@max_execution_time; 看是否为 0；再用纯命令行 mysql -e "SELECT SLEEP(10);" 测试，排除应用层干扰。
Workbench 执行脚本弹出 “Script execution interrupted” 怎么定位？
这是 Workbench 自己的 UI 层中断提示，不是 MySQL 报的错。它背后可能对应四种完全不同的根因：
- 语法层：某条语句末尾漏了
;，尤其在DELIMITER $$切换后忘记改回来，导致后续所有语句被吞掉 - 策略层：Preferences → SQL Editor → 勾选了
Stop script execution on error（默认开启），第一条报错（比如表不存在），后面全跳过 - 会话层：Workbench 底部状态栏显示
Connection lost，说明 TCP 连接已断，常见于wait_timeout超时（默认 8 小时）或防火墙 kill 空闲连接 - 基础设施层：
SHOW PROCESSLIST;里看到你的会话状态是Killed，那基本是 OOM 或 DBA 手动 KILL 了进程
关键动作：打开 Workbench 的 Output → Action Output 面板，看最后一行到底停在哪条语句；再查 Help → Show Log File，搜索 ERROR 或 disconnect。
Java 应用里抛出 “Query execution was interrupted” 却没改超时配置？
十有八九是代码里写了 statement.setQueryTimeout(5) 这类调用，而且单位是秒（不是毫秒）——JDBC 规范里就是秒，但很多人误以为是毫秒，设成 5 就等于强制 5 秒必断。
排查路径：
- 全局搜
setQueryTimeout，确认是否在 DAO 层或模板方法里硬编码了小数值 - 抓包看网络层有没有
KILL QUERY命令发出（Wireshark 过滤mysql.command == 0x02） - 在 MySQL 服务端开 general log：
SET GLOBAL general_log = 'ON';，看日志里是先出现你的 SQL，还是先出现KILL QUERY xxx
真正难搞的，是那种“有时快有时慢”的中断——它往往藏在连接池的健康检测逻辑里，比如 DBCP 的 testWhileIdle 配错了 validationQuery，导致空闲连接被误判失效，取出来一用就断。
