PostgreSQL 16存储过程性能瓶颈主要源于隐式全表扫描、未提交事务阻塞及循环中低效查询；卡顿常因长事务持锁，需查pg_stat_activity定位；应避免LOOP+SELECT、参数类型不匹配、EXCEPTION处理常规逻辑，并用EXPLAIN分析核心SQL。
PostgreSQL 16 中的存储过程（CREATE PROCEDURE）本身不返回值、不参与查询计划，优化重点不在“过程语法”，而在它内部执行的 SQL 和事务行为——绝大多数性能问题来自隐式全表扫描、未提交事务阻塞、或在循环中反复执行低效查询。
为什么 CALL 会卡住？查锁和事务状态
存储过程常被误认为“只是执行快”，但实际中卡顿多因它持有了长事务或未释放锁。比如一个批量更新的 PROCEDURE 在 BEGIN ... END 内没加 COMMIT，就会一直占用行锁。
- 先确认是否被锁：
SELECT blocked_pid, blocking_pid, blocked_statement FROM pg_stat_activity WHERE blocked_pid IS NOT NULL; - 检查该过程是否在长时间运行：
SELECT pid, state, backend_start, xact_start, query FROM pg_stat_activity WHERE query LIKE '%your_procedure_name%'; - 注意：PostgreSQL 16 不支持在
PROCEDURE内部使用COMMIT/ROLLBACK——除非用AUTONOMOUS TRANSACTION（需额外扩展如plpgsql_check或自定义 C 函数），否则事务边界由外部调用者控制
LOOP + SELECT 是最大性能杀手
常见写法是用游标或 FOR r IN SELECT ... LOOP 逐行处理，但每轮都触发一次查询解析、执行计划生成和 I/O，数据量一过万就明显变慢。
- 改用集合操作：把循环内单行
UPDATE改成基于JOIN或IN (SELECT ...)的批量语句 - 避免在循环里查同一张大表：提前用
CREATE TEMP TABLE AS SELECT ...缓存中间结果，再与之JOIN - 如果必须循环，加上
PERFORM pg_sleep(0.001)防止 CPU 占满（仅调试用，非解决根本）
参数传递不当导致索引失效
过程参数若参与 WHERE 条件但未显式类型匹配，PostgreSQL 可能无法复用已有索引，退化为顺序扫描。
- 错误示例：
WHERE created_at > $1::text（把timestamptz强转成 text）→ 索引失效 - 正确做法：声明参数时指定精确类型，如
IN p_start_time TIMESTAMPTZ，并在 WHERE 中直接用created_at >= p_start_time - 对
IN列表参数，不要拼接字符串；改用VARIADIC数组 += ANY()，例如：WHERE status = ANY(p_status_list)，配合GIN索引可加速
过程体里别用 EXCEPTION 拦截常规逻辑
EXCEPTION 块开销远高于普通 IF 判断，且 PostgreSQL 的异常处理机制会重置执行上下文，频繁触发会显著拖慢吞吐。
- 把“查不到就插入”这类逻辑改成
INSERT ... ON CONFLICT DO NOTHING，而不是先SELECT再INSERT并捕获unique_violation - 避免用
WHEN NO_DATA_FOUND替代IF NOT EXISTS (...)——前者是异常路径，后者是计划内分支 - 真要记录错误，用
RAISE LOG而非RAISE EXCEPTION，防止中断整个事务流程
真正难优化的不是过程语法本身，而是它封装了未经分析的慢查询、不可控的事务粒度、以及隐式类型转换——每次修改前，先用 EXPLAIN (ANALYZE, BUFFERS) 跑一遍过程里最重的那条 SQL，比调任何参数都管用。
