SQL审计表核心目标是准确、高效、低侵入记录关键操作，必备5字段：id、operation_time、operator、operation_type、table_name；需补充sql_statement、before_data、after_data、ip_address、app_name/trace_id等上下文；接入方案含触发器、应用层拦截、日志解析三种；运维须分区、设保留策略、禁直接删改、启行级安全。
SQL审计表的核心目标是准确、高效、低侵入地记录数据库关键操作，便于追溯、合规检查与安全分析。设计时需平衡完整性、性能和可维护性，不能只堆字段，也不能过度简化。
审计表必须包含的5个基础字段
这些字段构成审计日志的“骨架”，缺一不可：
-
id：主键，建议用 BIGINT 自增或 UUID（分布式场景优先 UUID）；
-
operation_time：操作发生时间，用 DATETIME(6) 或 TIMESTAMP(6)，精确到微秒，避免时区混乱（推荐存 UTC）；
-
operator：执行人标识，可以是数据库用户（如
current_user()）、应用层传入的工号/账号（更推荐），避免仅依赖 DB 用户名；
-
operation_type：枚举值，如
'INSERT'、'UPDATE'、'DELETE'、'DDL'、'EXECUTE_PROCEDURE'；
-
table_name：被操作的表名（非全路径，如
'user_profile'），便于按表聚合分析。
关键操作上下文：哪些内容要留痕？
光记“谁什么时候干了什么”不够，需补充可定位、可还原的上下文信息：
-
sql_statement：完整 SQL 文本（建议限制长度，如 VARCHAR(2000)），对敏感字段做脱敏处理（如手机号、身份证号自动替换为
***）；
-
before_data 和 after_data：JSON 格式，仅记录被修改字段的变更前/后值（UPDATE/DELETE 场景），避免整行快照浪费空间；
-
ip_address：客户端 IP（应用层透传最佳，DB 层获取可能为中间件地址）；
-
app_name / trace_id：关联业务系统名称和链路追踪 ID，方便跨系统问题排查。
如何低成本接入？三种实用方案对比
不依赖商业审计插件，也能实现可靠记录：
-
触发器方案：在重点表上建 AFTER INSERT/UPDATE/DELETE 触发器，写入审计表。优点是精准、无需改应用；缺点是增加 DML 延迟，DDL 操作无法覆盖，且难以统一管理；
-
应用层拦截方案：在 O
RM（如 MyBatis Interceptor、Spring AOP）或 DAO 层统一埋点。可控性强、可预处理敏感数据；需规范开发约束，存在漏埋风险；
-
数据库代理/日志解析方案：通过 MySQL 的 binlog（配合 canal）、PostgreSQL 的 logical decoding 解析真实变更。最全面（含所有 DML/DDL），零代码侵入；但部署运维复杂，延迟略高，需额外服务支撑。
日常运维与合规要点
审计表不是建完就完事，需持续运营：
- 设置自动分区（按 operation_time 月/周分区），避免单表过大影响查询和归档；
- 配置保留策略（如保留 180 天），定期归档冷数据至对象存储或数仓；
- 禁止直接 DELETE/UPDATE 审计表，应通过专用运维接口或 DBA 操作，并记录二次审计；
- 对审计表开启行级安全策略（如 RLS）或视图封装，确保普通应用只能 INSERT，不可 SELECT 敏感字段（如 before_data）。
RM（如 MyBatis Interceptor、Spring AOP）或 DAO 层统一埋点。可控性强、可预处理敏感数据；需规范开发约束，存在漏埋风险；