MySQL查询超时由服务端max_execution_time控制，仅对SELECT生效（5.7.8+，毫秒级），超时抛出“Query execution was interrupted”错误；wait_timeout等参数只管空闲连接，不中断执行中查询。
MySQL 查询超时不是靠 Linux 系统层配置，而是由 MySQL 服务端参数控制；Linux 只影响网络栈行为（如 net_read_timeout），真正能中止慢查询的是 MySQL 自身的 max_execution_time。
max_execution_time 是唯一能中断 SELECT 执行的参数
这个变量从 MySQL 5.7.8 起支持，只对 SELECT 生效，INSERT/UPDATE/DELETE 完全不响应它。它在 SQL 执行阶段计时，一旦超限就抛出错误：Query execution was interrupted, maximum statement execution time exceeded。
-
max_execution_time是会话级只读变量，不能写进my.cnf全局生效，必须每个连接建立后手动设（比如应用初始化时执行SET SESSION max_execution_time = 5000） - 值为
0表示明确禁用，不是“不限制” - 存储过程内部的
SELECT不继承会话设置，需在过程里显式SET SESSION - 需要当前用户有
PROCESS权限，否则 hint（如/*+ MAX_EXECUTION_TIME(3000) */）会被静默忽略
wait_timeout 和 interactive_timeout 管的是空闲连接，不是查询执行
这两个参数常被误认为是“查询超时”，其实它们只在连接**没有任何活动**时倒计时。哪怕一个 SELECT 已跑 10 分钟且还在算，只要没断开、没发新请求，wait_timeout 就完全不触发。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
wait_timeout控制非交互式连接（如 Java 应用 JDBC 连接） -
interactive_timeout控制交互式连接（如mysql -u root -p命令行） - 它们默认都是 28800 秒（8 小时），线上建议调低到 300–600 秒，但和“查太慢要停”无关
- 连接池的
idleTimeout必须小于wait_timeout，否则连接池可能拿到已失效的连接
net_read_timeout / net_write_timeout 只管网络收发，不管 SQL 执行
这两个参数作用于 TCP/IP 连接的数据传输阶段：前者是 MySQL 等待客户端发来下一段请求的超时，后者是 MySQL 往客户端发结果时卡住的超时。它们对查询逻辑本身无影响。
- 只对 TCP/IP 连接有效，Unix socket、命名管道等本地连接不走这个逻辑
- 如果查询已算完、正往客户端塞数据（状态为
Writing to net），此时KILL QUERY或max_execution_time都无效——线程仍在填 socket 缓冲区 - 默认值分别是 30 秒和 60 秒，若应用侧有大结果集导出场景，可适当调高，但别设成 0
- 它们不能替代
max_execution_time，因为计时不覆盖 SQL 解析、执行、锁等待等核心阶段
KILL QUERY 有时不生效的真实原因
执行 KILL QUERY [id] 后查询还在跑，大概率不是配置没设对，而是卡在 MySQL 无法中断的环节：
- 正在做 InnoDB 大事务回滚（rollback 不可中断，这是引擎硬限制）
- 卡在操作系统 I/O 层（比如磁盘满、页缓存刷盘慢），MySQL 已发中断信号但内核未响应
- 用了 UDF 或自定义存储引擎插件，且代码里没轮询
thd->killed标志位 - 查询处于
Sending data或Writing to net状态，结果集已生成，只是网络发不出去
这些场景下，max_execution_time 同样无效——它只在 SQL 引擎执行阶段起作用，不覆盖回滚、I/O、网络传输等外围环节。
