更新操作列值未变更场景下替代触发器的SQL审计方案咨询

针对你描述的性能不足、无法定位实际操作人、商业工具无法识别实际变更的场景，可按优先级选择以下方案：

方案1：轻量触发器+CDC（变更数据捕获）组合方案（改造成本最低，性能最优） #

• 原有触发器保留，但砍掉全量数据采集逻辑，仅在触发器内做两个操作：
  1. 用IF UPDATE(审计字段列表)做前置判断，只有指定审计字段的更新请求才往下执行，过滤无意义的触发
  2. 仅写入业务表主键ID、当前LastModifiedBy值、操作类型、操作时间到临时审计队列表，不做任何复杂比对或全量数据写入
• 开启数据库原生CDC功能，配置捕获对应业务表的变更前后数据，异步读取CDC快照和临时审计队列表的信息做关联，拼接生成完整审计日志
• 该方案下1000行数据更新操作耗时可控制在3秒以内，和原生更新性能差异小于10%，同时可完整获取所有字段的变更前后值，不会出现字段未更新就拿不到原始值的问题

方案2：自研事务日志解析脚本 #

• 直接调用数据库内置日志解析函数做轻量开发：SQL Server用fn_dblog()、MySQL用mysqlbinlog、PostgreSQL用pg_waldump
• 脚本逻辑只做3件事：
  1. 过滤指定业务表的UPDATE/INSERT/DELETE事务，提取事务LSN、操作时间、关联业务主键
  2. 从日志中拉取变更前后所有需要审计的字段值，包括LastModifiedBy字段
  3. 内置字段比对逻辑，仅当字段变更前后值不一致时，才将完整变更记录写入正式审计表
• 该方案对业务完全无侵入，不会对线上操作性能产生任何影响，可自主适配所有自定义审计规则

方案3：应用层埋点+CDC组合方案（扩展性最强） #

• 在应用DAO层做统一拦截，将当前登录用户身份、操作入口、请求参数等信息和对应业务操作的主键做绑定，写入独立的应用操作日志表
• 数据库端仅开启CDC异步采集数据变更内容，离线侧将应用操作日志和CDC变更数据按主键+时间窗口做关联，生成完整的审计链路
• 该方案后续新增审计维度不需要调整数据库逻辑，适配复杂业务场景的灵活性最高

落地注意事项 #

• 所有涉及日志捕获的方案，都需要提前配置合理的日志保留周期，避免日志被自动清理导致审计数据缺失
• 落地前验证业务逻辑中LastModifiedBy字段的赋值规则，确保所有插入、更新操作都会写入当前操作用户的正确标识，避免审计身份缺失
• 优先测试方案1，改造成本最低，90%以上的场景都可以满足要求

内容的提问来源于stack exchange，提问作者Darreninpelham