MySQL用max_execution_time控制SELECT超时（毫秒级，需启用optimizer_switch），PostgreSQL用statement_timeout统一控制所有操作；应用层驱动timeout覆盖更全生命周期，超时值需结合业务、数据量、并发及链路依赖综合设定。

MySQL中用max_execution_time控制单条SELECT超时

MySQL 5.7.8+ 支持在语句级设置执行时间上限，单位毫秒。它只对SELECT生效（INSERT/UPDATE/DELETE不触发），且需服务端启用optimizer_switch中的max_execution_time选项（默认开启）。

• 直接加提示：在查询开头加/<em>+ MAX_EXECUTION_TIME(3000) </em>/（注意是注释形式，不是SQL标准Hint语法，MySQL专用）
• 或通过SET会话变量：SET SESSION max_execution_time = 3000;，之后所有SELECT受约束
• 超时后返回错误：Query execution was interrupted, maximum statement execution time exceeded
• 不影响事务状态，但连接仍保持打开；客户端需捕获该错误并重试或降级

PostgreSQL用statement_timeout统一设查询超时

PostgreSQL没有语句级hint，靠参数控制。它对所有写/读操作都生效（包括SELECT、INSERT、函数调用等），单位是毫秒。

• 会话级设置：SET statement_timeout = 3000;
• 数据库级设置（需superuser）：ALTER DATABASE mydb SET statement_timeout = 3000;
• 连接字符串里也可传：postgresql://u:p@h/d?options=-c%20statement_timeout%3D3000
• 超时抛出ERROR: canceling statement due to statement timeout
• 注意：它会在查询执行中途强制中断，可能留下未释放的锁或临时表，尤其在复杂CTE或游标中要小心

应用层设置连接驱动的query timeout更可靠

数据库层超时有盲区：比如网络卡在发送阶段、DNS解析失败、连接池借出但未真正发SQL——这些max_execution_time和statement_timeout都管不到。

• JDBC：PreparedStatement.setQueryTimeout(3)（单位秒），底层触发java.sql.Statement.cancel()
• Python psycopg2：cursor.execute(sql, timeout=3)（需psycopg2 >= 2.8.6），或设options="-c statement_timeout=3000"在DSN里
• Go database/sql：ctx, _ := context.WithTimeout(context.Background(), 3*time.Second)，再传给db.QueryContext(ctx, sql)
• 关键点：驱动层timeout能覆盖整个请求生命周期（建连+发包+收响应），比DB参数更贴近真实用户体验

超时值设多少才合理？别只看P99延迟

设3秒还是30秒，不能只看历史慢查平均耗时。得结合：

• 业务场景：用户列表页可接受1–2秒，后台导出任务可放宽到300秒
• 数据量波动：分页深度增加、WHERE条件选择率下降时，执行计划可能劣化，超时应留余量
• 并发压力：高并发下IO争抢会导致同样SQL变慢，超时值要高于低峰期P99 * 2
• 链路依赖：如果SQL结果还要拼其他HTTP调用，整体链路timeout应大于SQL timeout + 网络毛刺缓冲（比如额外+500ms）

真正容易被忽略的是：超时不是万能开关。它不解决慢查询根因，只是兜底。一旦频繁触发，说明索引缺失、统计信息过期或JOIN方式不合理——得立刻查EXPLAIN ANALYZE，而不是只调大timeout。