postgresql 16 调试存储过程性能需结合 explain analyze、pg_stat_user_functions 统计、动态 sql 控制及 raise debug1 打点：前者分析执行路径，后者揭示函数级耗时分布，self_time 高说明 pl/pgsql 逻辑瓶颈，execute 可绕过计划缓存陷阱，分级日志辅助定位慢代码段。
PostgreSQL 16 里调试存储过程性能，不能只看函数是否“跑通”，关键得知道它慢在哪——是某条 SQL 执行拖垮整体，还是 PL/pgSQL 循环逻辑本身低效，又或是执行计划被缓存“锁死”了。直接上 EXPLAIN ANALYZE 是最可靠的第一步，但光靠它不够，得配合函数级统计、动态 SQL 控制和日志分级输出才能准确定位。
用 EXPLAIN ANALYZE 直接分析函数调用
PL/pgSQL 函数不是黑盒，EXPLAIN ANALYZE 能穿透进去看实际执行路径和耗时。但注意：它分析的是整个函数调用的外层语句（比如 SELECT * FROM my_func()），不会自动展开函数体里的每条 SQL —— 除非那些 SQL 是用 RETURN QUERY 或 EXECUTE 显式执行的。
- 对返回集合的函数，直接运行
EXPLAIN ANALYZE SELECT * FROM my_func(123);，能看到底层查询的真实actual time和loops - 对只做 DML 的
PROCEDURE，需包装成事务再测：BEGIN; CALL my_proc(123); EXPLAIN ANALYZE SELECT 1; COMMIT;（后者只是占位，重点看前面的 DML 是否触发了慢扫描） - 如果函数里用了
EXECUTE拼接 SQL，EXPLAIN ANALYZE无法预知其执行计划，必须在EXECUTE内部加RAISE NOTICE打印出最终语句，再单独EXPLAIN ANALYZE那条语句
查 pg_stat_user_functions 看函数级耗时分布
这个视图暴露了每个函数被调用多少次、总耗时、I/O 开销等真实运行数据，比手动计时靠谱得多。但它只统计“顶层调用”，不包含嵌套调用的子函数时间。
- 执行后立刻查：
SELECT funcname, calls, total_time, self_time FROM pg_stat_user_functions WHERE funcname = 'my_slow_func'; -
total_time包含所有子函数耗时，self_time才是该函数自身 PL/pgSQL 逻辑（如循环、赋值、条件判断）的纯开销 - 如果
self_time占比高，说明瓶颈在代码逻辑（比如FOR r IN SELECT ...遍历大量行），不是 SQL 本身；反之则聚焦查询优化 - 注意：该视图数据在连接断开或服务器重启后清零，生产环境建议定期快照
识别并绕过 PL/pgSQL 执行计划缓存陷阱
PostgreSQL 16 默认对 PL/pgSQL 函数内联的静态 SQL 做执行计划缓存，且缓存绑定到第一次调用的参数值。当后续参数导致数据分布差异大（比如查热门 ID vs 冷门 ID），缓存计划可能严重劣化。
- 典型症状：同一函数，传参
1很快，传参999999却慢 10 倍，EXPLAIN显示用了 Nested Loop 而非 Hash Join - 验证方式：改用
EXECUTE 'SELECT ... WHERE id = $1' USING user_id;强制每次重新生成计划 - 权衡点：动态 SQL 失去计划缓存收益，但换来稳定性；若参数范围有限（如只有几十个固定值），可用
format()拼接不同索引提示，或拆成多个专用函数 - 别碰
PREPARE+EXECUTE组合——在函数里这么干反而会引入额外解析开销，得不偿失
用 RAISE DEBUG/LOG 分级输出关键路径耗时
当 EXPLAIN 和统计视图都指向“PL/pgSQL 自身慢”，就得进代码里打点。用 RAISE DEBUG1 记录毫秒级时间戳，比肉眼估摸靠谱。
- 先设会话级：
SET client_min_messages = debug1;（否则客户端看不到DEBUG级消息） - 在函数开头/循环入口/关键计算前后插：
RAISE DEBUG1 'before loop: %', clock_timestamp(); - 避免在高频循环里狂打日志（比如每行都
RAISE），会拖慢百倍；改用计数器累计，循环结束后一次性输出：RAISE DEBUG1 'processed % rows in %', cnt, clock_timestamp() - start_ts; -
LOG级别消息写入服务器日志，适合长期监控；但需确保log_min_messages已设为log或更低，否则不落盘
真正卡住性能的，往往不是单条 SQL 写得差，而是 PL/pgSQL 层面的隐式行为：计划缓存误判、循环中反复执行未参数化的查询、或者用 SELECT INTO 把大结果集全加载进内存。调试时别急着重写逻辑，先让 pg_stat_user_functions 和 EXPLAIN ANALYZE 说话，再决定要不要动 EXECUTE 或 RAISE DEBUG1 这些手术刀。
