在金融、医疗、政务等对数据合规要求严格的行业，数据库审计几乎是绕不开的话题。PostgreSQL自带的日志系统虽然能记录所有执行的SQL，但日志信息混杂，无法清晰区分哪些是敏感操作、由哪个角色发起、属于哪个业务会话，事后追溯时要从海量日志中人工筛拣，效率极低。pgAudit扩展正是为了解决这个问题而生的，它在PostgreSQL标准日志之上提供会话级和对象级的精细化审计能力，输出的日志带有统一的AUDIT前缀，便于日志采集系统识别和归档。本文将系统讲解pgAudit的原理、安装、配置和实战技巧。
pgAudit的工作原理与审计模式
pgAudit之所以能在PostgreSQL上实现精细审计，靠的是PostgreSQL提供的扩展钩子机制。普通扩展只能注册到进程内库，而pgAudit通过shared_preload_libraries预加载后，挂载到ExecutorStart_hook和ProcessUtility_hook等执行钩子上。当SQL语句经过解析器生成语法树后，钩子函数会捕获完整的语句结构，从中提取对象名、命令类型等信息，再按照配置的规则决定是否输出审计日志。这意味着pgAudit记录的是解析后的规范化语句，而不是简单的字符串拼接，因此能准确识别出语句真正操作的对象。
pgAudit提供两种审计模式。第一种是会话级审计（Session Audit Logging），通过pgaudit.log参数指定要审计的语句类别，例如READ、WRITE、FUNCTION、ROLE、DDL、MISC等，命中类别的所有语句都会被记录。这种方式配置简单、覆盖面广，适合对整个数据库实例做全量审计。第二种是对象级审计（Object Audit Logging），通过pgaudit.role参数指定一个审计角色，凡是对该角色拥有权限的对象进行的操作都会被记录。对象级审计弥补了会话级审计无法细化到具体表或视图的不足，比如只想审计对某张核心资金表的SELECT操作，用对象级审计最合适。
需要理解的一点是，pgAudit的日志输出走的是PostgreSQL标准日志通道，也就是最终写入日志收集器进程的输出，日志格式会带有一个统一的AUDIT:前缀。这个设计的好处是可以直接复用现有的日志轮转、采集和告警体系，比如用file_fdw或logstash抓取AUDIT开头的行做集中分析。
pgAudit的安装与基础配置
安装pgAudit的前提是PostgreSQL必须以--with-openssl之外的一个关键方式编译，更重要的是需要完整的源码或开发包。以Linux环境为例，先从官方网站下载pgAudit源码，解压后执行编译安装。整个过程依赖PATH中能找到正确的pg_config，如果你的PostgreSQL安装在非标准路径，需要显式指定。
# 下载并解压pgAudit源码（以1.7版本为例） wget https://github.com/pgaudit/pgaudit/archive/refs/tags/1.7.0.tar.gz tar -xzf 1.7.0.tar.gz cd pgaudit-1.7.0 # 指定pg_config路径后编译安装 make PG_CONFIG=/usr/pgsql-16/bin/pg_config make PG_CONFIG=/usr/pgsql-16/bin/pg_config install
编译安装完成后，pgAudit还不能直接使用，必须修改postgresql.conf中的shared_preload_libraries参数。这是因为钩子机制要求在服务启动时就加载扩展库，普通CREATE EXTENSION做不到这一点。配置好后重启数据库，再在目标数据库中执行CREATE EXTEDURE时注意拼写，正确的语句是CREATE EXTENSION pgaudit;。完整的配置流程如下：
# 编辑postgresql.conf，添加或修改以下参数 shared_preload_libraries = 'pgaudit' pgaudit.log = 'ddl,write' # 审计DDL和写操作 pgaudit.log_catalog = off # 不记录对系统目录的查询，减少噪音 pgaudit.log_parameter = on # 记录语句的绑定参数 pgaudit.log_relation = on # 按对象分别记录SELECT/DML日志 # 重启数据库使预加载生效 systemctl restart postgresql-16 # 在目标库中创建扩展 psql -d mydb -c "CREATE EXTENSION pgaudit;"
配置生效后，执行一条DDL语句验证，日志中应出现类似AUDIT: SESSION,1,1,DDL,CREATE TABLE,...的条目。其中SESSION表示会话级审计，后面的字段依次是语句ID、子语句ID、命令类型、命令标签以及完整的语句文本。确认有日志输出后，基础环境就搭建完成了。
审计策略的精细化设置
仅仅全局设置pgaudit.log往往不够灵活。实际业务中常见的诉求是：只审计某个数据库、只审计某个角色，或者不同角色采用不同严格程度的审计。这些都可以通过PostgreSQL的ALTER ROLE和ALTER DATABASE语法实现参数的按用户覆盖。例如让审计账号记录所有类别的语句，而报表账号只记录READ：
-- 针对特定角色设置审计级别，登录时生效 ALTER ROLE auditor SET pgaudit.log = 'ALL'; ALTER ROLE reporter SET pgaudit.log = 'read'; -- 针对特定数据库设置审计，连入该库时生效 ALTER DATABASE finance SET pgaudit.log = 'ddl,write,role'; -- 对象级审计：创建审计角色并授予目标表权限 CREATE ROLE audit_reader; GRANT SELECT ON public.accounts TO audit_reader; SET pgaudit.role = 'audit_reader';
关于pgaudit.log的取值，需要记住几个关键类别：READ覆盖SELECT和COPY读写源，WRITE覆盖INSERT、UPDATE、DELETE和TRUNCATE，FUNCTION记录函数调用及DO块，ROLE记录用户和权限相关操作，DDL记录所有数据定义语句，MISC则覆盖DISCARD、FETCH、CHECKPOINT等杂项命令。类别之间用逗号分隔，也支持none表示关闭、all表示全部开启。此外还有一个实用的pgaudit.log_client参数，默认审计日志只写入服务端日志文件，开启该参数后还会发送到客户端，方便开发调试阶段确认审计行为。
对象级审计有两个容易踩坑的地方。其一，pgaudit.role引用的角色必须是当前会话中启用的角色链的一部分，通常在配置角色权限后需要SET ROLE或重新登录才能生效。其二，对象级审计只对被授予审计角色的对象生效，权限判断走的是标准的权限检查流程，因此如果对象本身设置了REVOKE，审计也会随之失效。建议在设计对象级审计前先梳理清楚角色权限模型，避免审计范围与预期不符。
日志管理与性能注意事项
开启审计必然带来日志量的增长，做好日志管理是长期运行的关键。首先要合理设置log_rotation_age和log_rotation_size，建议按天或按100MB切割日志，配合日志归档脚本定期压缩转移。其次要善用日志前缀参数，开启log_line_prefix中的%u（用户名）、%d（数据库名）、%h（客户端地址）等字段，这样每条审计日志都自带上下文，排查时不需要再回查会话记录。
# postgresql.conf中推荐的日志相关配置 log_destination = 'csvlog' logging_collector = on log_directory = 'log' log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log' log_rotation_age = 1d log_rotation_size = 100MB log_line_prefix = '%m [%p] %u@%d %h ' log_truncate_on_rotation = on
性能方面，pgAudit的开销主要来自语句解析后的对象提取和日志格式化。经验数据显示，对纯OLTP高并发写入场景，开启全量write审计大约带来百分之几的性能损耗，通常可以接受；但如果把READ也加入审计且业务以查询为主，日志量会急剧膨胀，磁盘IO压力明显上升。缓解办法有三种：一是开启pgaudit.log_catalog = off过滤掉对系统目录的海量重复查询；二是避免在业务低峰期无关的类别上做全量审计，改用对象级审计只盯核心表；三是把日志输出指向独立磁盘，避免审计日志与数据文件争抢IO。
最后提醒几个运维细节：升级PostgreSQL大版本时，pgAudit必须针对新版本重新编译，主从复制环境中审计日志只需在主库配置，流复制的备库不执行本地写操作；如果使用连接池软件如PgBouncer，要注意审计记录的是池化后连接的信息，建议让每个业务使用独立的数据库用户，保证审计日志中的%u字段能真实反映操作来源。把pgAudit与定期的日志采集分析平台打通，一套可追溯的数据库审计体系就真正落地了。
pgAuditPostgreSQL审计日志数据库审计修改时间：2026-09-02 08:34:39