> ## 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.

# Resolve Findings

> Investigate, remediate, re-review, and document SQL findings in a traceable workflow.

The goal of remediation is not merely to reduce the number of findings. Each decision should remove or consciously accept the underlying risk, preserve required SQL behavior, and leave enough evidence for another reviewer to understand the outcome.

## Goal

Investigate, remediate, re-review, and document SQL findings so that each risk is removed or consciously accepted with evidence.

## Prerequisites

A review ticket with findings to resolve, and access to modify and re-review the SQL.

## Remediation loop

```mermaid theme={null}
flowchart TD
    A["Verify finding and context"] --> B{"Change required?"}
    B -->|Yes| C["Modify and test SQL"]
    C --> D["Run review again"]
    B -->|No| E["Document acceptance"]
    D --> F{"Resolved?"}
    F -->|No| A
    F -->|Yes| G["Complete review"]
    E --> G
```

## Work through a finding

<Steps>
  <Step title="Verify the trigger">
    Read the rule, SQL location, and related objects. Confirm the database version and workspace context.
  </Step>

  <Step title="Assess actual impact">
    Determine whether the issue affects correctness, performance, security, maintainability, or release safety.
  </Step>

  <Step title="Choose a disposition">
    Modify the SQL, correct incomplete context, fix ticket configuration, or request an authorized exception.
  </Step>

  <Step title="Validate the change">
    Test semantics and, where appropriate, performance so that results and data effects remain correct.
  </Step>

  <Step title="Run the review again">
    Reuse the same policy and workspace unless a deliberate revision is part of the change. Compare the new result with the original.
  </Step>

  <Step title="Record the outcome">
    Preserve the change, evidence, residual risk, owner, and related ticket or approval.
  </Step>
</Steps>

## Common dispositions

| Situation                                   | Recommended response                                                |
| ------------------------------------------- | ------------------------------------------------------------------- |
| SQL genuinely violates the rule             | Correct it, test it, and request re-review                          |
| Missing metadata caused a misleading result | Refresh the workspace and run the review again                      |
| The wrong database version was selected     | Correct the target configuration and repeat the review              |
| A rule does not apply to this case          | Document the technical basis and use the exception process          |
| One issue repeats across many statements    | Fix the shared pattern in controlled batches and sample the results |
| A recommendation may change semantics       | Do not apply it automatically; obtain developer and DBA review      |

## Validate remediated SQL

Confirm at least the following:

* the target database can parse the SQL;
* query results or data-change semantics remain correct;
* transaction, locking, and concurrency behavior is acceptable;
* index or rewrite candidates provide value under representative conditions;
* the original issue is gone and no new high-risk finding has appeared;
* required testing, approval, deployment, and rollback controls are complete.

<Warning>
  Do not deploy generated or recommended SQL without validation. DDL, wide-impact DML, locking-sensitive changes, and data repair must follow your organization’s database change process.
</Warning>

## Accept a finding as an exception

When remediation is not appropriate, use the exception process in [Manual Review and Approval](/en/user-guide/sql-audit/manual-review-and-approval): record the business rationale, impact, and compensating controls, and keep the exception to the narrowest scope. Do not weaken a global policy to accommodate one isolated case.

## Remediate at scale

* Prioritize by severity, system criticality, and execution frequency.
* Group findings by rule to expose reusable fixes.
* Change SQL in small batches with regression coverage.
* Compare risk distribution and performance evidence before and after remediation.
* Feed proven patterns back into engineering standards and review policies.

## Expected Result

After remediation and re-review, the resolved findings no longer trigger, no new high-risk finding appears, and the outcome is recorded with evidence.

## Next steps

For blocking issues, see [Control High-Risk SQL](/en/user-guide/sql-audit/high-risk-sql-control). When a person must make the final disposition, continue to [Manual Review and Approval](/en/user-guide/sql-audit/manual-review-and-approval).