本页关注计划的呈现与瓶颈定位。优化前后的代价验证与判定见 自动化性能验证。
概览
数据库执行计划通常包含大量层级信息、成本估算、行数估算和算子属性。 对于复杂 SQL，直接阅读原生文本计划往往非常困难。 PawSQL 将执行计划转换为可视化结构：为什么执行计划分析很重要
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 数据倾斜
- 分布式数据移动
优化前后对比
与自动化性能验证配合，可比较：- 原始执行计划
- 查询重写优化后执行计划
- 智能索引推荐后执行计划
示例
假设原始执行计划：- 为什么访问路径变化
- 哪个节点 Cost 降低
- 扫描数据量是否下降
- 新索引是否真正生效
执行计划分析不只是漂亮的树
一个专业的执行计划工具不应该只把文本转成图。 真正有价值的执行计划分析还应帮助用户回答：Where is the cost? Why is it expensive? What changed after optimization?
数据库感知的执行计划解析
不同数据库的 EXPLAIN 输出结构差异很大。 PawSQL 需要将不同数据库执行计划映射到统一模型，同时保留数据库专项信息，例如：- MySQL access type
- PostgreSQL plan nodes
- Oracle operations
- SQL Server physical operators
- DB2 explain operators
- Distributed database exchange / motion nodes