目标
对 SQL 审核问题进行确认、修改、复核和例外记录，形成可追踪的闭环。准备工作
有一张包含待处理问题的审核工单，并具备修改 SQL 和重新审核的权限。处理流程
逐项处理
1
确认触发原因
阅读规则说明、SQL 位置和相关对象，检查数据库版本及工作空间是否正确。
2
评估业务影响
确认问题是否影响正确性、性能、安全、可维护性或发布流程。
3
选择处理方式
修改 SQL、补充上下文、调整不适用的工单配置，或按流程申请保留。
4
验证修改
执行语义校验、测试和必要的性能验证，确保结果集及数据变更符合预期。
5
重新审核
使用相同或明确升级后的策略和工作空间再次审核，比较问题变化。
6
记录结论
保存修改内容、验证证据、剩余风险、处理人和关联单据。
常见处理方式
修改后的验证
至少确认：- SQL 可以被目标数据库正确解析；
- 查询结果或数据变更语义未改变；
- 事务、锁和并发行为符合预期；
- 索引或重写建议在代表性数据上有效；
- 原问题不再触发，且没有新增高风险问题；
- 测试、审批和回退要求已经满足。
保留问题和例外
确需保留某个问题时，进入人工复核与审批的例外流程：记录业务依据、影响范围和补偿控制，并把例外限定在最小范围。不要通过降低全局规则级别来处理单个例外。批量治理建议
- 按高风险、核心系统和高频 SQL 排序；
- 按规则聚类，识别可以统一修复的模式；
- 小批量修改并进行回归验证；
- 对比修复前后的问题分布和性能数据；
- 将成熟做法沉淀到开发规范和审核策略。