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选项（默认开启）。
- 直接加提示：在查询开头加
/+ MAX_EXECUTION_TIME(3000) /（注意是注释形式，不是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。
