SQL 审计日志不是简单记录“谁执行了什么”，而是要支撑安全回溯、责任认定和合规检查。关键在于字段设计合理、采集粒度可控、权限变更可关联。
核心审计字段必须包含哪些
只记 SQL 语句或只记用户名远远不够。以下字段建议作为基础必填项：
-
执行时间（带毫秒+时区）：避免跨时区排查歧义，推荐用
TIMESTAMP WITH TIME ZONE类型存储 - 客户端 IP + 主机名：区分是应用服务器代发还是 DBA 直连，必要时可反向 DNS 验证
-
数据库用户 + 应用用户（如有）：例如
db_user='app_pool'，app_user='u12345'，用于穿透权限代理场景 - 会话 ID / 连接 ID：串联同一次连接中的多条语句，识别事务边界
-
SQL 摘要 + 参数化标识：对 DML/DDL 记录标准化后的语句模板（如
UPDATE users SET status = ? WHERE id = ?），避免敏感值落盘 -
影响行数（仅限 DML）：INSERT/UPDATE/DELETE 后由驱动返回的
rowcount，不依赖解析 SQL
权限变更必须单独建表追踪
GRANT/REVOKE 本身是 DDL，但混在通用审计流里易被忽略。建议独立表结构并触发强通知：
- 表名建议为
audit_privilege_changes，字段含：change_time, grantor, grantee, privilege_type（SELECT/INSERT/ROLE）, object_type（TABLE/SCHEMA/DB）, object_name, is_grant_option, is_with_hierarchy - 对
postgres或pg_monitor等高危角色赋权，自动触发企业微信/钉钉告警 - 定期比对
pg_roles和历史授权记录，识别未登记的权限漂移
避免审计性能反噬业务
全量记录每条语句可能拖慢 OLTP 系统。需分层控制采集策略：
- 默认只记录
ERROR级别及以上操作（如权限拒绝、语法错误、死锁中断），降低写入压力 - 对敏感表（如
users、payments）开启STATEMENT级别审计，无论成功失败都记 - 使用异步日志队列（如 Kafka + Logstash）承接审计数据，数据库侧只做轻量写入
- 定期归档冷数据到对象存储，保留最近 90 天热数据供实时查询
权限与行为必须能交叉验证
单看权限列表不知是否真被使用；单看 SQL 日志不知执行者是否有权。两者需可关联分析：
- 审计日志中增加
effective_role_path字段，记录当前会话实际生效的角色继承链（如app_user → app_reader → pg_read_all_data） - 在权限变更表中存快照式
role_inheritance_graph（JSONB），便于回溯某次查询发生时的真实权限上下文 - BI 工具中构建「用户-权限-操作」三元透视视图，支持按表、按角色、按时间段下钻
