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

# Performance Validation

> Validate SQL rewrites and index recommendations using target-database optimizers, execution plans, and cost comparison.

PawSQL Performance Validation determines whether a SQL optimization actually improves the execution plan instead of relying only on static rules, expert intuition, or language-model speculation.

It moves SQL optimization from **recommendation** to **validation**.

<Note>
  This page focuses on **comparison and judgment** — whether the optimized SQL is actually better. For **visual rendering of plans and bottleneck location**, see [Execution Plan Analysis](/en/features/execution-plan-visualization).
</Note>

## Overview

A SQL statement that looks cleaner is not necessarily faster.

An index that looks reasonable is not necessarily used by the optimizer.

After generating a SQL rewrite or index recommendation, PawSQL can compare the original and optimized execution plans and optimizer costs to determine whether the candidate is likely to provide a real benefit.

```mermaid theme={null}
flowchart LR
    A["Original SQL"] --> B["Original Plan"]
    B --> C["Optimization"]
    C --> D["Optimized Plan"]
    D --> E["Cost Comparison"]
    E --> F["Result"]
```

## Why Validation Matters

One of the most common mistakes in SQL optimization is assuming that “theoretically faster” means “actually faster.”

An optimization may fail because:

* The optimizer still chooses the same access path
* Real data selectivity differs from expectations
* A new index costs more than it saves
* A rewrite introduces additional sorting or materialization
* Database versions or statistics change optimizer behavior
* Distributed databases introduce extra data movement

Performance Validation reduces this uncertainty by using information from the real target-database optimizer.

## Key Capabilities

### Before-and-after plan comparison

Compare the execution plans of original and optimized SQL.

Key changes include:

* Scan type
* Join algorithm
* Join order
* Sort and aggregate operations
* Estimated data volume
* Distributed data movement

### Cost comparison

Compare optimizer cost or equivalent estimated metrics.

Cost is not the same as execution time, but it is an important signal for ranking and validating optimization candidates.

### Index validation

Determine whether a recommended index:

* Is actually selected by the optimizer
* Changes the access path
* Reduces scanned rows
* Reduces sort or join cost

### Rewrite validation

Determine whether a SQL rewrite improves the execution strategy rather than merely changing syntax.

### Optimization scoring

In batch-governance scenarios, optimization priority can incorporate:

* Cost reduction
* Execution frequency
* Current SQL cost
* Risk severity

## Example

Original SQL:

```sql theme={null}
SELECT *
FROM orders
WHERE customer_id = 100;
```

Optimization candidate:

```sql theme={null}
CREATE INDEX idx_orders_customer
ON orders(customer_id);
```

Validation should answer:

1. Does the optimizer switch from a full table scan to an index scan?
2. Does the optimizer cost decrease?
3. Does the estimated row volume decrease significantly?
4. Does an equivalent index already exist?
5. Is the read benefit worth the write and maintenance overhead?

Only after these questions are answered does the index recommendation become an engineering decision rather than a generic suggestion.

## Validation Loop

```mermaid theme={null}
flowchart LR
    A["Detect"] --> B["Optimize"]
    B --> C["Validate"]
    C --> D["Compare"]
    D --> E["Accept / Reject"]
```

This creates a closed optimization loop instead of a static recommendation list.

## Cost Is Evidence, Not Absolute Truth

Database cost is an optimizer estimate, not actual runtime.

Therefore:

* Cost is useful for candidate comparison
* Plan structure should be analyzed together with cost
* Critical production SQL may require runtime evidence
* Cost should be interpreted carefully when statistics are inaccurate

## Related Capabilities

<CardGroup cols={2}>
  <Card title="SQL Quality Check" icon="list-check" href="/en/features/sql-review" />

  <Card title="Query Rewrite" icon="wand-sparkles" href="/en/features/automatic-sql-rewrite" />

  <Card title="Index Recommendation" icon="layers" href="/en/features/index-recommendation" />

  <Card title="Execution Plan Analysis" icon="list-tree" href="/en/features/execution-plan-visualization" />

  <Card title="Supported Databases" icon="database" href="/en/getting-started/supported-databases" />
</CardGroup>

## Related Use Cases

<CardGroup cols={2}>
  <Card title="Developer SQL Copilot" icon="code" href="/en/use-cases/developer-sql-copilot" />

  <Card title="DBA Batch Slow SQL Governance" icon="gauge" href="/en/use-cases/slow-sql-optimization" />

  <Card title="SQL Quality Gate" icon="git-merge" href="/en/use-cases/sql-quality-gate-cicd" />

  <Card title="Enterprise SQL Governance Platform" icon="building-2" href="/en/use-cases/enterprise-sql-governance" />
</CardGroup>
