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

# Control High-Risk SQL

> Govern high-risk database changes through policy enforcement, validation, release gates, and time-bounded exceptions.

High-risk SQL controls prevent significant, unverified database risk from moving silently into a release. Effective control combines policy-based detection with human judgment, representative testing, and the organization’s change-management process.

<Note>
  Blocking, exception, approval, and quality-gate features depend on PawSQL edition, licensing, and integration configuration. Where an in-product workflow is unavailable, use the PawSQL review report as evidence in an external ticketing or CI/CD gate.
</Note>

## Goal

Control high-risk database changes by combining policy-based detection with human judgment, representative testing, and the organization's change-management process.

## Prerequisites

A production-ready review policy with blocking or high severity assigned to critical rules, and an established change-management and exception process.

## Typical risk categories

| Category                     | Example exposure                                       | Primary controls                                                    |
| ---------------------------- | ------------------------------------------------------ | ------------------------------------------------------------------- |
| Data integrity               | Broad updates or deletes without adequate predicates   | Scope validation, backup, rollback, and independent review          |
| Schema change                | DDL that may block application traffic                 | Lock impact, duration, compatibility, and maintenance window        |
| Query performance            | Full scans, Cartesian joins, or oversized result sets  | Data scale, execution plan, indexing, and resource limits           |
| Transactions and concurrency | Long transactions, hot-row updates, or lock contention | Transaction boundaries, concurrency, timeout, and observability     |
| Access and compliance        | Privileged operations or sensitive-object access       | Execution identity, least privilege, authorization, and audit trail |

Your organization’s review policies define which cases are high risk.

## Recommended control flow

<Steps>
  <Step title="Detect automatically">
    Use a production-ready policy and assign blocking or high severity to critical rules.
  </Step>

  <Step title="Establish the operating context">
    Confirm the target environment, affected objects, data volume, execution duration, and maintenance window.
  </Step>

  <Step title="Reduce risk first">
    Correct the SQL, split the operation, narrow predicates, or choose a safer execution approach.
  </Step>

  <Step title="Validate under controlled conditions">
    Test semantics, plans, runtime, locking behavior, stop conditions, and rollback readiness.
  </Step>

  <Step title="Handle unavoidable exceptions">
    Submit the rationale, compensating controls, and expiration date for authorized review.
  </Step>

  <Step title="Release with evidence">
    Continue only after the gate is satisfied, and retain the review, approval, and execution record.
  </Step>
</Steps>

## Suggested gate decisions

| Condition                                          | Recommended outcome                                           |
| -------------------------------------------------- | ------------------------------------------------------------- |
| An unresolved blocking finding exists              | Stop the workflow                                             |
| High-risk findings were remediated and re-reviewed | Continue through the standard release process                 |
| A valid exception covers the high-risk finding     | Continue only within the approved scope and conditions        |
| Review coverage is incomplete                      | Pause, correct the input or context, and run the review again |
| Policy or workspace changed                        | Repeat the review before making a decision                    |

## Handle exceptions

When a risk cannot be removed, use the exception process in [Manual Review and Approval](/en/user-guide/sql-audit/manual-review-and-approval): submit the rationale, compensating controls, and an expiration date for authorized review, and bind the exception to a specific SQL statement, rule, project, environment, and validity period.

<Warning>
  Urgency does not remove the need for risk assessment. An emergency change should still retain the minimum necessary review, authorization, backup, monitoring, and rollback controls.
</Warning>

## Integrate with CI/CD or ticketing

An automated workflow can evaluate ticket status, highest severity, unresolved finding counts, or a report outcome. Design the integration to:

* pin or record the review-policy revision;
* define safe behavior for failures, timeouts, and incomplete analysis;
* prevent unauthorized users from bypassing the gate;
* retain the ticket link, report, and pipeline evidence;
* provide a controlled manual fallback for service incidents.

See [SQL Quality Gate](/en/features/sql-quality-gate) and [SQL Quality Gate for CI/CD](/en/use-cases/sql-quality-gate-cicd) for related patterns.

## Expected Result

Each high-risk change is detected, remediated or covered by a time-bounded exception, and released only after the gate is satisfied with retained evidence.

## Verification

Confirm that no unresolved blocking finding remains and that the gate decision matches the recommended outcome before proceeding.

## Next step

When an authorized person must decide whether the change can proceed, see [Manual Review and Approval](/en/user-guide/sql-audit/manual-review-and-approval).