审计日志须存user_id、session_user、current_user、client_hostname、client_addr、target_object、grantee及operation_type等字段，并用pg_audit插件捕获权限操作上下文，避免仅依赖sql_text。
审计日志该存哪些字段才够追踪权限变更
只记 user_id 和 sql_text 不足以还原“谁在什么时间、用什么身份、改了哪个对象的什么权限”。权限类操作（如 GRANT、REVOKE、CREATE ROLE）必须捕获执行上下文。
-
session_user和current_user都要存——前者是登录身份，后者可能因SET ROLE或函数内SECURITY DEFINER变动 - 加
client_hostname和client_addr，否则无法区分同名用户从不同终端发起的操作 - 对 DCL 语句，额外提取目标对象：用正则或解析器从
sql_text中捕获ON table_name、TO role_name等片段，写入独立字段（如target_object、grantee），别全堆在大文本里 - 避免记录完整
sql_text超过 2000 字符——容易拖慢写入，且敏感内容（如密码字面量）可能意外落盘；可截断并加标记[TRUNCATED]
PostgreSQL 中用 pg_audit 还是自己监听 log_statement
pg_audit 插件比单纯开 log_statement = 'ddl' 更可靠，但它默认不记录 current_user 的实际值，也不区分会话级角色切换。
- 启用
pg_audit后，必须设置pg_audit.log_catalog = off，否则系统表操作（如pg_roles更新）会产生海量无关日志 -
log_statement在all模式下会记录所有 SQL，但权限类语句混在普通查询里难过滤；而pg_audit支持ROLE类别，专抓权限相关动作 - 注意
pg_audit的日志输出依赖logging_collector = on，且默认写入 CSV 文件——如果要用 SQL 查询分析，得定期导入或换用pgaudit_log_to_db = on（需 1.4+ 版本） - 不要关掉
log_line_prefix，至少保留%m %u %r（时间、用户、客户端地址），否则日志条目失去时序和来源锚点
MySQL 权限变更怎么避免漏记 FLUSH PRIVILEGES
MySQL 的权限表（mysql.user 等）被直接 UPDATE 后，不执行 FLUSH PRIVILEGES，内存缓存不会更新——但审计日志若只监听 FLUSH 语句，就完全错过真正的权限修改。
- 必须开启
general_log或使用performance_schema的events_statements_history，才能捕获对mysql库的INSERT/UPDATE/DELETE -
binlog_format = ROW时，mysql库的 DML 不写 binlog（除非显式设sql_log_bin = 1），所以不能依赖 binlog 解析做审计 - 用触发器拦截
mysql.user表变更不可行——系统表不支持用户定义触发器 - 推荐方案：定期（如每分钟）对比
mysql.user表的CHECKSUM TABLE值，并记录差异行的host、user、authentication_string哈希，再结合general_log定位操作者
审计日志表设计时最容易被忽略的性能陷阱
权限审计日志写入频繁但查询稀疏，很多人直接建 TEXT 字段存整条 SQL，结果半年后单表超千万行，SELECT * FROM audit_log WHERE sql_text LIKE '%GRANT%' 全表扫描卡死。
- 把
operation_type（'GRANT'、'REVOKE'、'DROP ROLE'）单独建CHAR(10)字段并加索引，WHERE 条件优先走它 -
sql_text字段用TEXT，但禁止在它上面建全文索引——MySQL 的FULLTEXT对短关键词（如GRANT）效果差，PostgreSQL 的to_tsvector开销大；真要搜内容，用pgroonga或外部 ES - 分区按天或按月（如
PARTITION BY RANGE (created_at)），但别用HASH分区——查“某用户上周所有权限操作”需要扫全部分区 - 别忘了
VACUUM（PG）或OPTIMIZE TABLE（MySQL）维护，长期运行后膨胀率超 30% 会让 INSERT 变慢
权限审计不是记流水账，关键在能快速反向定位“谁、何时、通过什么方式、改了什么”。字段设计和采集方式稍有偏差，后面排查时花的时间会指数级增长。
