statement_timeout是PostgreSQL会话级参数，单位毫秒，超时后终止当前语句并返回ERROR: canceling statement due to statement timeout，不中断连接或自动回滚事务。
statement_timeout 是什么，超时后会发生什么
statement_timeout 是 PostgreSQL 的会话级参数，单位为毫秒，用于限制单条 SQL 语句的执行时长。一旦语句运行超过该阈值，PostgreSQL 会主动中止执行，并向客户端返回错误：ERROR: canceling statement due to statement timeout。这不是连接断开，也不是事务回滚（除非该语句在事务中且未显式处理），而是语句级强制终止——后续语句仍可继续执行，但当前语句的结果丢失、不会写入任何数据。
如何设置 statement_timeout：会话级、用户级、数据库级的区别
设置方式不同，生效范围和优先级也不同：
- 会话级（最常用）：
SET statement_timeout = 30000;（30 秒），只影响当前连接，适合临时调试或关键查询加保护 - 用户级：
ALTER USER myuser SET statement_timeout = '10s';，新连接该用户时自动生效，适合对特定应用账号统一约束 - 数据库级：
ALTER DATABASE mydb SET statement_timeout = '5s';，影响所有连到该库的新会话，但会被用户级或会话级覆盖 - 全局配置（不推荐直接改）：在
postgresql.conf中设statement_timeout = 5s，重启生效，影响所有数据库所有用户，灵活性差且易误伤
注意：0 表示禁用超时（默认值），SET 命令中的数值可带单位如 '5s'、'300ms'，PostgreSQL 会自动转换为毫秒整数。
业务代码里怎么安全应对 statement_timeout 触发
不能假设 SQL 总能成功返回——超时是正常错误场景，必须在应用层显式捕获并降级处理：
- 检查驱动是否抛出可识别异常：如 Python psycopg2 抛
psycopg2.OperationalError，且.pgcode == '57014'（PostgreSQL 错误码对应 statement timeout） - 避免在事务中无防护地执行长查询：超时后事务仍处于 active 状态，后续语句会报
current transaction is aborted, commands ignored until end of transaction block；必须先ROLLBACK再继续 - 对非关键查询做 fallback：比如报表页的“最近活跃用户”统计超时，可返回缓存结果或提示“数据暂不可用”，而非让整个页面失败
- 不要依赖重试机制盲目重放超时语句：可能加重负载，尤其当超时源于锁争用或资源瓶颈时，应先分析慢因再决定是否重试
statement_timeout 和 lock_timeout、idle_in_transaction_session_timeout 的关系
这三个 timeout 解决不同问题，常被混淆：
-
statement_timeout：语句执行时间过长（CPU/IO 耗尽） -
lock_timeout：等待行锁或表锁的时间超限（如被其他事务长时间持有），触发时抛57014同码但上下文不同 -
idle_in_transaction_session_timeout：事务空闲太久（如应用拿到事务后没提交也没执行），防事务悬挂，触发时断开连接
它们可以共存，但需注意：若一个语句既慢又等锁，lock_timeout 通常先于 statement_timeout 触发；而事务空闲超时是连接级的，和语句执行无关。线上建议三者都设合理值，但必须分别监控和告警。
真正麻烦的是嵌套场景：比如函数里调用另一个可能超时的函数，或者 prepared statement + 参数化查询在不同数据分布下耗时波动极大——这时候单靠 statement_timeout 不够，得结合查询计划分析、索引优化和应用层分页/采样控制。
