mysql查询超时由服务端控制，核心参数是max_execution_time（中止慢查询）和wait_timeout（断开空闲连接）；单条select可用max_execution_time提示设置毫秒级时限，超时返回中断错误。
MySQL 查询超时由谁控制？
MySQL 查询是否超时、超时后怎么处理，不是靠客户端“喊停”，而是服务端主动中断。核心控制权在 wait_timeout 和 max_execution_time 两个参数手上，但它们管的事完全不同：wait_timeout 管的是「空闲连接」多久断开，对正在跑的查询完全没用；真正能中止慢查询的是 max_execution_time（5.7.8+ 才支持）。
如何给单条 SELECT 加执行时间限制？
最直接的方式是用 MAX_EXECUTION_TIME 提示（hint），只影响当前语句，不改配置也不影响其他会话：
SELECT /*+ MAX_EXECUTION_TIME(3000) */ * FROM huge_table WHERE ...;
单位是毫秒，这里表示最多跑 3 秒，超时后返回错误：Query execution was interrupted, maximum statement execution time exceeded。注意几点：
-
MAX_EXECUTION_TIME只对SELECT生效，INSERT/UPDATE/DELETE不认这个 hint - 需要确保会话有
PROCESS权限，否则 hint 被静默忽略 - 如果查询已进入锁等待（比如等行锁），计时器不会暂停——超时时间包含等待时间
全局或会话级设置 max_execution_time 的坑
可以通过 SET SESSION max_execution_time = 5000 给后续所有 SELECT 设默认上限，但要注意：
- 该变量是只读会话级变量，不能写进
my.cnf全局配置；必须每个连接建立后手动设，或者由应用层统一初始化 - 值为 0 表示禁用限制，不是“不限制”，而是明确关掉机制
- 它不作用于存储过程内部的
SELECT，除非在过程里显式调用SET SESSION - 和
innodb_lock_wait_timeout完全无关，后者只管锁等待，不管执行逻辑耗时
为什么 kill 掉连接有时也停不下来？
执行 KILL QUERY [id] 或 KILL CONNECTION [id] 后查询还在跑，常见原因有：
- 查询正卡在操作系统层面（比如磁盘 I/O、网络发送缓冲区满），MySQL 已发中断信号，但内核还没响应
- 用了 UDF（用户自定义函数）或存储引擎插件，且代码里没定期检查
thd->killed标志位 - 正在执行大事务的回滚（rollback），而回滚不可中断——这是 InnoDB 的硬限制
- 查询处于
Writing to net状态，说明结果集已经算完，正在往客户端发数据；此时 kill 只会断开连接，服务端线程仍需把剩余数据塞进 socket 缓冲区
这类场景下，max_execution_time 同样无效，因为它只在 SQL 执行阶段起作用，不覆盖结果传输或回滚过程。
