MySQL中真正能中止慢SELECT的只有max_execution_time（5.7.8+，毫秒级），仅对独立SELECT生效，不作用于DML、存储过程、锁等待及结果传输；可通过语句级hint（/+ MAX_EXECUTION_TIME(3000) /）、会话级SET SESSION或全局SET GLOBAL设置，但需PROCESS权限且值为0表示禁用。
MySQL 本身不提供对所有 SQL 类型统一生效的查询超时机制，真正能中止慢 SELECT 的只有 max_execution_time；DML（INSERT/UPDATE/DELETE）和事务回滚不受它控制，必须靠应用层 timeout 或人工干预。
只对 SELECT 生效的 max_execution_time 怎么设？
这个参数是 MySQL 5.7.8+ 引入的，单位毫秒，只中断正在执行的 SELECT，不碰 DML、存储过程内部语句，也不管锁等待或结果传输阶段。
- 语句级最灵活：在 SQL 开头加注释提示，比如
SELECT /*+ MAX_EXECUTION_TIME(3000) */ * FROM orders WHERE ...—— 注意是/*+开头，不是标准 SQL Hint，MySQL 专用 - 会话级更省事：执行
SET SESSION max_execution_time = 3000后，该连接后续所有SELECT都受控；但值为 0 表示明确关闭，不是“不限制” - 全局级需谨慎：用
SET GLOBAL max_execution_time = 3000影响新连接，但已有连接不变；不能写进my.cnf，重启后失效，必须每次初始化连接时重设 - 权限要求：使用 hint 或 SET SESSION 需要有
PROCESS权限，否则静默忽略
为什么 KILL QUERY 有时没用？
执行 KILL QUERY 后查询还在跑，常见于以下几种情况，max_execution_time 同样无效：
- 查询卡在操作系统层：比如磁盘 I/O 堵塞、TCP 发送缓冲区满，MySQL 已发中断信号，但内核未响应
- 用了 UDF 或插件函数，且代码里没定期检查
thd->killed标志位 - 正在执行大事务回滚——InnoDB 回滚不可中断，这是存储引擎硬限制
- 状态是
Writing to net：SQL 早就算完了，只是在往客户端发数据；此时KILL只断连接，线程还得把剩余数据塞进 socket 缓冲区
应用层 query timeout 才是兜底方案
数据库参数管不到建连、DNS 解析、网络发送失败这些环节，真正覆盖完整生命周期的是驱动层 timeout：
- JDBC：
PreparedStatement.setQueryTimeout(3)（单位秒），底层调java.sql.Statement.cancel() - psycopg2（Python）：
cursor.execute(sql, timeout=3)（需 >= 2.8.6），或在 DSN 里传options="-c statement_timeout=3000" - Go：
ctx, _ := context.WithTimeout(context.Background(), 3*time.Second)，再传给db.QueryContext(ctx, sql) - 关键点：这类 timeout 能中断整个请求链路，包括等连接池、发包、收响应，比服务端参数更贴近真实用户感知
别混淆 wait_timeout 和 max_execution_time
这两个参数常被混用，但完全无关：
-
wait_timeout控的是「空闲连接」：连接建立后 10 分钟没发任何命令，MySQL 就断开它；对正在跑的SELECT或UPDATE一点作用没有 -
max_execution_time控的是「SELECT 执行耗时」：从解析开始计时，含锁等待时间，超时后报错Query execution was interrupted, maximum statement execution time exceeded - 还有个
innodb_lock_wait_timeout，它只管「等行锁多久放弃」，和执行逻辑耗时无关
真正难处理的是那些已提交但尚未完成回滚的大事务，或者卡在 OS 层的查询——它们既不响应 max_execution_time，也很难被 KILL 干净终止。这时候得靠监控 + 自动化 kill 工具（比如 pt-kill）配合业务侧熔断策略来兜住。
