在PostgreSQL数据库中，函数（function）是封装业务逻辑的常用手段，尤其是使用PL/pgSQL编写的存储过程函数，往往承担着大量核心计算任务。当系统出现性能瓶颈时，一个很自然的问题是：某个函数到底被调用了多少次？每次调用平均花费多长时间？为了回答这个问题，PostgreSQL在统计信息体系中提供了两个视图：pg_stat_user_functions和pg_stat_xact_user_functions。前者记录的是实例级别的累计数据，后者则专门统计当前事务内的调用情况。本文将围绕pg_stat_xact_user_functions展开，介绍它的工作原理、字段含义、使用方法以及适用场景。
一、pg_stat_xact_user_functions的基本原理
pg_stat_xact_user_functions属于PostgreSQL统计收集器（statistics collector）体系中的一员，但它有一个特殊之处：它的数据并不写入统计文件，而是直接保存在每个后端进程自己的内存中。这意味着它的数据是事务级的、进程私有的，不会跨事务累积。当事务提交或回滚时，这些数据会被合并到全局的pg_stat_user_functions视图中，然后清零重新开始。
这种设计带来一个直接的好处：你可以在事务执行过程中实时查看当前事务对函数的调用情况，而不必等到事务结束。这对调试一个长事务内部的行为非常有价值。例如，一个批量处理的存储过程运行了十几分钟，你可以在另一个会话中查看它的执行进度和函数热点，这在只使用累计视图时是无法做到的。
需要注意的是，该视图只统计用户自定义函数，系统内置函数不会出现在结果中。另外，只有被标记为需要跟踪的函数才会被统计，这就涉及配置参数track_functions。
二、字段含义与配置要求
pg_stat_xact_user_functions视图包含四个字段，理解每个字段的含义是正确使用它的前提。可以用下面的SQL查看表结构：
-- 查看视图结构 \d pg_stat_xact_user_functions -- 查询视图数据 SELECT * FROM pg_stat_xact_user_functions;
四个字段的含义如下表所示：
| 字段名 | 类型 | 说明 |
|---|---|---|
| funcid | oid | 函数的对象标识符，可用于关联pg_proc系统表 |
| calls | bigint | 当前事务内该函数被调用的次数 |
| total_time | double precision | 当前事务内该函数所有调用消耗的总时间，单位毫秒 |
| self_time | double precision | 扣除内部调用其他被跟踪函数后的自身耗时，单位毫秒 |
total_time和self_time的区别值得特别注意。如果一个函数A内部又调用了函数B，且两者都被跟踪，那么函数A的total_time包含了调用B的时间，而self_time则不包含。通过对比这两个值，可以分析出函数内部的调用链耗时分布。此外，统计函数调用本身是有开销的，PostgreSQL默认关闭了这个功能，需要设置参数track_functions才能启用。它有三个可选值：off表示不跟踪，pl表示只跟踪过程语言函数（如PL/pgSQL编写的函数），all表示跟踪包括SQL语言函数在内的所有函数。可以在会话级别动态设置：
-- 在当前会话启用跟踪，覆盖所有函数类型 SET track_functions = 'all'; -- 只跟踪过程语言函数（默认推荐，开销较小） SET track_functions = 'pl'; -- 关闭跟踪 SET track_functions = 'off';
建议只在排查问题时临时开启，定位完毕后关闭，避免对生产环境带来额外开销。
三、实际使用示例
下面通过一个完整的例子演示如何使用该视图分析函数调用。首先创建两个函数，模拟一个调用链：
-- 开启跟踪
SET track_functions = 'pl';
-- 创建一个内部函数
CREATE OR REPLACE FUNCTION calc_discount(p_price numeric)
RETURNS numeric AS $$
BEGIN
-- 模拟一定计算量
PERFORM pg_sleep(0.01);
RETURN p_price * 0.9;
END;
$$ LANGUAGE plpgsql;
-- 创建一个外部函数，内部调用内部函数
CREATE OR REPLACE FUNCTION batch_process(p_count int)
RETURNS void AS $$
DECLARE
i int;
BEGIN
FOR i IN 1..p_count LOOP
PERFORM calc_discount(i * 100);
END LOOP;
END;
$$ LANGUAGE plpgsql;
然后在同一个事务中调用外部函数，并查询统计视图：
BEGIN;
SELECT batch_process(10);
-- 查看当前事务内的函数调用统计
SELECT p.proname AS 函数名,
s.calls AS 调用次数,
round(s.total_time::numeric, 2) AS 总耗时,
round(s.self_time::numeric, 2) AS 自身耗时
FROM pg_stat_xact_user_functions s
JOIN pg_proc p ON p.oid = s.funcid
ORDER BY s.total_time DESC;
-- 输出结果类似于：
-- batch_process 调用1次 总耗时105ms 自身耗时4ms
-- calc_discount 调用10次 总耗时101ms 自身耗时101ms
COMMIT;
从结果可以清晰看出：batch_process虽然只被调用了一次，但它内部调用了calc_discount十次，几乎占满了整个执行时间。事务提交后再次查询pg_stat_xact_user_functions会发现数据已清空，而累计值则可以在pg_stat_user_functions中查到，这正是两个视图协作的方式。
如果想进一步分析平均每次调用的耗时，可以在查询中做简单计算：
SELECT p.proname,
s.calls,
round((s.total_time / s.calls)::numeric, 3) AS 平均耗时ms
FROM pg_stat_xact_user_functions s
JOIN pg_proc p ON p.oid = s.funcid
WHERE s.calls > 0
ORDER BY 平均耗时ms DESC;
四、与pg_stat_user_functions的区别及适用场景
pg_stat_xact_user_functions与pg_stat_user_functions的字段结构完全相同，但数据范围不同。前者只反映当前事务，后者反映实例启动以来或上次重置以来的累计数据。这个差异决定了二者的适用场景完全不同。
pg_stat_xact_user_functions适合的场景包括：第一，调试单个事务，观察事务内部哪些函数被触发、执行了多少次；第二，单元测试或回归测试中验证函数是否按预期被调用；第三，分析长事务的中间状态，配合其他会话查询可以实时监控进度；第四，需要干净的测试环境，避免历史数据干扰，因为每次事务开始计数都是零，无需手动重置。
而pg_stat_user_functions更适合长期的趋势分析，比如统计过去一段时间内哪些函数是系统热点、对比两次快照之间某函数的调用量变化等。需要注意的是，如果测试想使用累计视图，通常要先执行pg_stat_reset()清空历史数据，这会影响全局统计，因此在生产库上要谨慎操作。相比之下，事务级视图天生具备隔离性，不会影响其他会话。
最后提醒两点常见误区：一是忘记设置track_functions参数，导致视图始终为空；二是误以为该视图能统计所有系统内置函数的调用，实际上它只覆盖用户定义的函数。掌握这些细节后，pg_stat_xact_user_functions就能成为分析函数执行行为的一把利器，无论是排查慢查询还是优化存储过程内部逻辑，都能提供精确的数据支撑。
pg_stat_xact_user_functions函数调用统计PostgreSQL性能监控修改时间：2026-09-01 07:14:59