> ## Documentation Index
> Fetch the complete documentation index at: https://docs.pawsql.com/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> PawSQL 是一个产品：Cloud 是公网部署形态，Engine / Optimizer / Auditor / Advisor / Patroller 是同一产品的组件与交付形态，不是彼此独立的产品。 / PawSQL is a single product: Cloud is the public deployment form, while Engine / Optimizer / Auditor / Advisor / Patroller are components and delivery forms of the same product, not separate products.
> 术语以站内术语表为准：SQL 审核对应英文 SQL Review，查询重写对应 Query Rewrite，索引推荐对应 Index Recommendation；英文内容统一用 Review，不用 Audit。 / Use the site glossary for terminology: 审核 is SQL Review, 重写 is Query Rewrite, 索引推荐 is Index Recommendation; English content uses Review, never Audit.
> 引用能力范围或版本支持时以对应页面为准；标注 unknown、或 status 非 published 的内容表示尚未经产品核实，不应作为事实引用。 / Cite capability scope and version support from the corresponding page; content marked unknown, or with a status other than published, is not yet product-verified and must not be cited as fact.

# 人工复核与审批

> 在自动审核基础上完成人工复核、例外审批和放行记录。

人工复核用于确认自动规则无法完整判断的业务语义、环境影响和例外条件。审批结论应以审核结果和验证证据为依据，而不是替代技术检查。

<Note>
  界面中的典型流转是：自动审核完成后，提交人点击“提交复核”将工单提交给审批人；审批人在“审批历史”标签页查看审批时间线并作出最终决策；审批通过后的执行情况记录在“执行记录”标签页。内置审批、角色分离和状态流转取决于 PawSQL 版本、License 及组织配置。若当前版本未提供，可在外部工单系统中完成审批，并关联 PawSQL 审核工单或报告。
</Note>

## 目标

在自动审核基础上完成人工复核、例外审批和放行记录。

## 角色与职责

| 角色        | 主要职责                  |
| --------- | --------------------- |
| 提交人       | 提供 SQL、目标环境、变更说明和验证结果 |
| 开发负责人     | 确认业务语义、影响范围和测试覆盖      |
| DBA 或审核人员 | 复核数据库风险、执行方案和回退措施     |
| 审批人       | 对高风险例外或最终放行作出授权结论     |
| 项目管理员     | 维护权限、策略和审计要求          |

实际角色可以合并，但生产高风险变更建议避免由提交人单独完成全部审批。

## 复核材料

提交人工复核前，准备：

* PawSQL 审核工单或报告；
* 目标数据库、版本、Schema 和环境；
* SQL 变更内容及业务目的；
* 未解决问题和保留原因；
* 影响范围、数据量及执行窗口；
* 测试结果和必要的性能证据；
* 备份、监控、停止条件和回退方案；
* 关联需求、缺陷或变更单。

## 复核流程

<Steps>
  <Step title="检查审核完整性">
    确认所有 SQL 均已解析，策略和工作空间适用于目标环境。
  </Step>

  <Step title="复核未解决问题">
    逐项判断风险是否已消除、可接受或需要补充验证。
  </Step>

  <Step title="核对发布条件">
    检查执行身份、窗口、备份、监控、回退和通知安排。
  </Step>

  <Step title="给出结论">
    根据权限选择通过、退回修改或有条件通过，并填写理由。
  </Step>

  <Step title="保存记录">
    记录处理人、时间、意见、附件及关联工单，确保可以追溯。
  </Step>
</Steps>

## 建议结论

| 结论    | 适用情况             | 后续动作       |
| ----- | ---------------- | ---------- |
| 通过    | 风险已处理，验证和发布条件完整  | 进入下一发布环节   |
| 退回修改  | 存在未解决风险或资料不足     | 修改并重新审核    |
| 有条件通过 | 风险获授权接受，且有明确控制措施 | 按批准条件执行并复查 |
| 取消    | SQL 或变更计划不再执行    | 关闭工单并记录原因  |

状态名称以实际产品或外部流程为准。

## 审批意见要求

有效的审批意见应说明“为什么”和“在什么条件下”，例如：

* 哪些问题已验证或获例外；
* 例外适用的 SQL、环境和有效期限；
* 执行前必须完成的条件；
* 监控指标、停止条件和回退负责人；
* 是否需要执行后复查。

避免只填写“同意”“已确认”等无法解释决策依据的内容。

## 例外与豁免

确需接受某个问题而不修改时，将例外限定在最小范围（明确 SQL、规则、项目、环境和有效期），并记录：

* 例外原因和业务必要性；
* 风险所有者和审批人；
* 影响对象与预计数据量；
* 补偿控制，例如限流、监控、备份或回退；
* 执行窗口、监控指标和停止条件；
* 到期时间，避免永久豁免。

不要通过降低全局规则级别来处理单个例外。若产品提供忽略、豁免或审批能力，应按最小范围设置并保留审计记录。

<Warning>
  SQL、审核策略、工作空间或执行环境在批准后发生实质变化时，原结论可能不再有效。应重新审核并按流程再次复核。
</Warning>

## 权限与审计建议

* 按角色授予提交、复核、审批和策略管理权限；
* 限制审批人修改原始 SQL 或审核结果；
* 记录状态变化、操作人和时间；
* 定期复查长期有效的例外；
* 对生产高风险变更设置更严格的授权要求。

## 预期结果

工单记录有据可依的通过、退回或有条件通过结论，并保存理由、证据和审计轨迹。

## 验证

确认审批意见包含决策理由和适用范围，且审批时间线与执行记录反映最终结论。

## 下一步

审批完成后，参阅[审核历史、报告与导出](/user-guide/sql-audit/history-reports-and-export)保存和查询审计记录。