> ## 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.
# 自动化性能验证
> 使用目标数据库优化器、执行计划与 Cost 对比验证查询重写优化和索引优化是否真正有效。
PawSQL 自动化性能验证用于验证 SQL 优化是否真正改善执行计划，而不是仅依赖静态规则、经验判断或语言模型推测。
它把 SQL 优化从“推荐”推进到“验证”。
本页关注**比较与判定**——优化前后是否真的更好。执行计划的**可视化呈现与瓶颈定位**见 [执行计划分析](/features/execution-plan-visualization)。
## 概览
一条 SQL 看起来更简洁，并不代表执行更快。
一个索引看起来合理，也不代表数据库优化器一定会使用它。
因此，PawSQL 在生成查询重写优化或智能索引推荐后，可以进一步比较优化前后的执行计划与 Cost，以判断候选方案是否真正带来收益。
```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"]
```
## 为什么验证很重要
SQL 优化中最常见的问题之一，是把“理论上可能更快”误认为“实际上更快”。
以下情况都可能导致优化建议无效：
* 优化器仍然选择原来的访问路径
* 数据选择性与预期不同
* 新索引成本高于收益
* 重写 SQL 导致额外排序或物化
* 数据库版本或统计信息改变优化结果
* 分布式数据库产生额外数据移动
自动化性能验证用真实数据库优化器的信息降低这种不确定性。
## 核心能力
### 优化前后执行计划对比
比较原始 SQL 与优化 SQL 的执行计划。
重点关注：
* Scan 类型变化
* Join 算法变化
* Join 顺序变化
* Sort / Aggregate 变化
* 数据访问量变化
* 分布式数据移动变化
### 代价对比
比较数据库优化器给出的 Cost 或等价估算指标。
Cost 并不等同于真实执行时间，但可以作为优化候选筛选与自动验证的重要信号。
### 索引验证
判断推荐索引是否：
* 被优化器实际使用
* 改变访问路径
* 降低扫描行数
* 降低排序或 Join 成本
### 重写验证
判断查询重写优化是否真正改善执行策略，而不仅仅是代码形式变化。
### 优化评分
在批量 SQL 治理场景中，可以基于：
* Cost 改善幅度
* SQL 执行频率
* SQL 当前成本
* 风险等级
形成优化优先级。
## 示例
原始 SQL：
```sql theme={null}
SELECT *
FROM orders
WHERE customer_id = 100;
```
优化建议：
```sql theme={null}
CREATE INDEX idx_orders_customer
ON orders(customer_id);
```
验证时需要回答：
1. 优化器是否从 Full Table Scan 转为 Index Scan？
2. Cost 是否下降？
3. 预计扫描行数是否明显减少？
4. 是否已有等价索引？
5. 新索引是否值得承担写入与维护成本？
只有这些问题得到合理答案，索引建议才真正具有工程价值。
## 验证闭环
```mermaid theme={null}
flowchart LR
A["Detect"] --> B["Optimize"]
B --> C["Validate"]
C --> D["Compare"]
D --> E["Accept / Reject"]
```
这使 SQL 优化形成闭环，而不是停留在建议列表。
## 代价是证据，不是绝对真理
数据库 Cost 是优化器内部估算值，并不等于真实耗时。
因此：
* Cost 适合用于候选方案比较
* 执行计划结构应与 Cost 一起分析
* 对关键生产 SQL，可进一步结合真实执行数据
* 统计信息不准确时，应谨慎解释 Cost
## 相关能力
## 相关场景