mysql中唯一能在执行器层面中断select的超时参数是max_execution_time（5.7.8+，毫秒级），仅对最外层独立select生效，不覆盖锁等待、事务回滚、网络传输等阶段；update等dml需依赖innodb_lock_wait_timeout控锁等待，而全链路超时必须由应用层驱动实现。
MySQL 的 max_execution_time 只对独立 SELECT 生效，根本拦不住 UPDATE、锁等待、事务回滚或网络发包阶段——想靠它防“慢查询堆积”，大概率会漏掉真正卡住连接的环节。
MySQL 中哪些超时参数真能中断 SELECT？
max_execution_time 是唯一能在执行器层面掐断 SELECT 的参数（5.7.8+），单位毫秒，但有硬限制：
- 只作用于最外层
SELECT，INSERT ... SELECT或存储过程里的SELECT不触发 - 不覆盖锁等待阶段：状态是
Waiting for lock时计时器根本没启动 - 超时后返回错误
Query execution was interrupted, maximum statement execution time exceeded，连接仍保持打开，需客户端主动处理 - 必须确保
optimizer_switch中的max_execution_time选项开启（默认开，但可被误关）
UPDATE/DELETE 被卡住时，该设哪个超时？
UPDATE 卡住，90% 是在等锁，不是执行慢。这时候 max_execution_time 完全无效，得用 innodb_lock_wait_timeout：
- 设为
SET SESSION innodb_lock_wait_timeout = 10（单位秒），超时抛Lock wait timeout exceeded - 必须在
BEGIN之后、UPDATE之前设置，否则事务已开始竞争锁，再设无效 - MySQL 8.0.19+ 支持设为 0 表示“立即失败”，老版本最小值是 1
- 注意：它和
max_execution_time互不干扰，一个管“等锁”，一个管“执行”
为什么应用层 timeout 才是兜底关键？
数据库参数管不到建连、DNS 解析、TCP 发送缓冲区满、客户端崩溃这些环节。真正覆盖完整链路的是驱动层 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) - SQLAlchemy：
session.query(...).execution_options(timeout=10).all()（1.4+）
这类 timeout 能中断整个请求生命周期，包括从连接池取连接、发包、收响应——这才是用户真实感知到的“超时”。
容易被忽略的三个盲区
很多人设了 max_execution_time 就以为万事大吉，但以下情况它完全不生效：
- 状态显示
Writing to net：SQL 早执行完了，只是在往客户端塞数据；此时 KILL 只断连接，线程还得把剩余数据灌进 socket 缓冲区 - 用了 UDF 或插件函数，且代码里没定期检查
thd->killed标志位，MySQL 发了中断信号但函数不响应 - 大事务回滚中：InnoDB 回滚不可中断，这是存储引擎硬限制，任何超时参数都无效
