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 Linux Hardware Debug

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、网络传输等外围环节。