PostgreSQL执行SQL时出现 ERROR: canceling statement due to statement timeout，表示语句运行时间超过当前生效的 statement_timeout，服务器主动取消了这条语句。它不等于数据库崩溃，也不能直接证明问题来自锁等待。
官方文档说明，该时间从命令到达服务器开始计算，默认值0表示禁用。处理时要先查当前值从哪里设置，再判断语句是在计算、I/O还是等待锁。
先确认当前值和配置来源
在发生问题的同一账号、数据库和连接方式下执行：
SHOW statement_timeout;
SELECT name, setting, unit, source, sourcefile, sourceline, pending_restart
FROM pg_settings
WHERE name = 'statement_timeout';source 可以帮助判断值来自默认设置、配置文件、数据库、角色、客户端或会话。连接池还可能在建连后执行 SET，因此管理员终端看到的值未必与应用连接相同。
不要只检查postgresql.conf就认定参数没有启用。 ALTER ROLE ... SET、ALTER DATABASE ... SET、连接字符串options和应用初始化SQL都可能覆盖服务器默认值。
区分慢执行和锁等待
在另一条有监控权限的连接中查看活动会话：
SELECT pid, usename, application_name, client_addr, state,
wait_event_type, wait_event,
now() - query_start AS running_for,
query
FROM pg_stat_activity
WHERE state <> 'idle'
ORDER BY query_start;wait_event_type = 'Lock' 表示语句正在等锁；I/O、Client或其他等待事件需要结合业务判断。没有等待事件并不代表SQL正常，它也可能正在大量计算或扫描数据。
SELECT blocked.pid AS blocked_pid,
blocker.pid AS blocker_pid,
blocked.query AS blocked_query,
blocker.query AS blocker_query
FROM pg_stat_activity AS blocked
JOIN pg_stat_activity AS blocker
ON blocker.pid = ANY(pg_blocking_pids(blocked.pid));先保存超时SQL、参数值和等待状态，再终止会话。 超时发生后现场很快消失，没有证据就调大阈值，容易把锁竞争或执行计划问题隐藏起来。
用执行计划定位真正瓶颈
对只读查询先使用不实际执行的计划：
EXPLAIN (VERBOSE, COSTS, SETTINGS)
SELECT ...;确认语句安全、数据量可控且处于维护或测试环境后，再考虑：
EXPLAIN (ANALYZE, BUFFERS, SETTINGS)
SELECT ...;重点观察实际行数与估算行数差异、顺序扫描、排序落盘、重复循环和缓存命中。必要时更新统计信息，并根据过滤、连接和排序条件设计索引。
EXPLAIN ANALYZE 会真正执行SQL。 不要直接对未知成本的写入语句或生产重查询运行它，否则可能再次触发锁、写入和资源消耗。
按最小范围调整statement_timeout
临时诊断可只调整当前会话：
SET statement_timeout = '60s';
SHOW statement_timeout;只希望当前事务中的一段任务生效，可使用：
BEGIN;
SET LOCAL statement_timeout = '60s';
-- 执行业务SQL
COMMIT;需要长期按业务账号或数据库设置时，可使用 ALTER ROLE 或 ALTER DATABASE，并让连接池重新建立连接。官方文档不建议直接在postgresql.conf中为所有会话统一设置非零值，因为会影响不同类型的工作负载。
优先按角色、数据库、会话或单个事务缩小影响范围。 无限增大超时会让坏查询更久占用CPU、I/O、连接和锁，并不等于完成优化。
正确理解与其他超时的区别
statement_timeout 统计整条语句从到达服务器到完成的时间；lock_timeout 只在等待获取锁时计时。若两者都启用，较早达到的限制会先终止语句。
SHOW statement_timeout;
SHOW lock_timeout;
SHOW idle_in_transaction_session_timeout;idle_in_transaction_session_timeout 处理的是事务已打开但会话空闲的情况。不要用statement_timeout代替连接池超时、HTTP请求超时或空闲事务治理。 每一层超时都应留出清晰的先后关系，方便应用正确识别错误并回滚。
需要在不影响生产的环境重放慢查询时，可用 萤光云 建立测试数据库，或使用 LightNode 做短时性能验证。数据必须脱敏，配置与生产版本也要一致。
修改后如何验收
重新建立应用连接，确认实际生效值和SQL执行时间：
SHOW statement_timeout;
SELECT calls, total_exec_time, mean_exec_time, rows, query
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 10;第二条查询需要预先启用 pg_stat_statements，未启用时不要为验收临时重启生产库。还应检查应用是否在收到超时错误后正确回滚事务，而不是继续复用失败事务。
验收标准是目标SQL在合理资源范围内完成、超时值来源清晰，且应用能正确处理取消和回滚。 只看到错误数量下降，不能证明锁竞争或慢计划已经消失。
FAQ
把statement_timeout设为0可以解决问题吗？
0表示不限制语句时长，只会让报错消失，不会修复慢SQL、锁等待或资源不足。生产服务通常需要保留符合SLA的上限。
为什么psql正常，应用却持续超时？
两者可能使用不同角色、数据库、连接参数或初始化SQL。应在应用实际连接中读取 SHOW statement_timeout，并检查连接池设置。
超时后事务还能继续使用吗？
若超时发生在显式事务中，事务通常会进入失败状态，需要执行ROLLBACK后再继续。应用不应无条件重试同一事务。
温馨提示
调整数据库超时前，先记录原值、来源、目标SQL和业务SLA。 最稳妥的方案通常是优化执行计划与锁范围，再为不同业务角色设置可解释、可监控的超时边界。
