> ## 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.
# 执行计划分析
> 将复杂数据库执行计划转换为更易理解的图形结构，帮助快速定位高成本算子、扫描、Join、排序与数据流问题。
PawSQL 执行计划分析将数据库原生执行计划转换为更直观的图形结构，帮助开发者和 DBA 更快理解 SQL 的执行路径。
它不仅展示“有哪些算子”，还用于辅助识别 SQL 性能瓶颈、解释优化结果，并比较优化前后的执行计划差异。
本页关注**计划的呈现与瓶颈定位**。优化前后的**代价验证与判定**见 [自动化性能验证](/features/performance-validation)。
## 概览
数据库执行计划通常包含大量层级信息、成本估算、行数估算和算子属性。
对于复杂 SQL，直接阅读原生文本计划往往非常困难。
PawSQL 将执行计划转换为可视化结构：
```mermaid theme={null}
flowchart LR
A["Database EXPLAIN"] --> B["Plan Parser"] --> C["Plan Model"] --> D["Operator Analysis"] --> E["Visual Plan"]
```
## 为什么执行计划分析很重要
SQL 性能优化本质上是在理解数据库“准备如何执行 SQL”。
仅看 SQL 文本无法回答很多关键问题：
* 数据库是否使用索引？
* 哪个表发生了全表扫描？
* Join 使用 Hash Join 还是 Nested Loop？
* 哪个节点成本最高？
* Sort 或 Aggregate 是否成为瓶颈？
* 预计行数是否发生明显膨胀？
* 分布式数据库是否发生数据重分布？
执行计划提供这些信息，而可视化可以显著降低阅读复杂计划的成本。
## 核心能力
### 执行计划树可视化
以树形或图形方式展示执行计划节点以及父子关系。
典型算子包括：
* Table Scan
* Index Scan
* Index Seek
* Nested Loop
* Hash Join
* Merge Join
* Sort
* Aggregate
* Materialize
* Exchange / Redistribute
### 代价可视化
在执行计划节点上展示：
* Node Cost
* Total Cost
* Estimated Rows
* Actual Rows（如果数据库提供）
* Width / Data Volume
* Execution Time（如果计划包含）
### 瓶颈识别
帮助快速定位：
* 高成本节点
* 全表扫描
* 大规模 Sort
* 行数膨胀
* Nested Loop 大表循环
* Join 数据倾斜
* 分布式数据移动
### 优化前后对比
与自动化性能验证配合，可比较：
* 原始执行计划
* 查询重写优化后执行计划
* 智能索引推荐后执行计划
从而直观看到访问路径发生了什么变化。
## 示例
假设原始执行计划：
```text theme={null}
Nested Loop
├── Seq Scan orders
└── Index Scan customers
```
优化后：
```text theme={null}
Hash Join
├── Index Scan orders
└── Index Scan customers
```
可视化不仅帮助用户看到算子变化，还应帮助解释：
* 为什么访问路径变化
* 哪个节点 Cost 降低
* 扫描数据量是否下降
* 新索引是否真正生效
## 执行计划分析不只是漂亮的树
一个专业的执行计划工具不应该只把文本转成图。
真正有价值的执行计划分析还应帮助用户回答：
**Where is the cost? Why is it expensive? What changed after optimization?**
因此 PawSQL 可以将可视化与以下能力结合：
```mermaid theme={null}
flowchart TD
V["Visualization
快速理解执行路径"]
A["Analysis
识别高成本与异常算子"]
C["Validation
比较优化前后的计划变化"]
```
## 数据库感知的执行计划解析
不同数据库的 EXPLAIN 输出结构差异很大。
PawSQL 需要将不同数据库执行计划映射到统一模型，同时保留数据库专项信息，例如：
* MySQL access type
* PostgreSQL plan nodes
* Oracle operations
* SQL Server physical operators
* DB2 explain operators
* Distributed database exchange / motion nodes
## 相关能力
## 相关场景