本页关注比较与判定——优化前后是否真的更好。执行计划的可视化呈现与瓶颈定位见 执行计划分析。
概览
一条 SQL 看起来更简洁，并不代表执行更快。 一个索引看起来合理，也不代表数据库优化器一定会使用它。 因此，PawSQL 在生成查询重写优化或智能索引推荐后，可以进一步比较优化前后的执行计划与 Cost，以判断候选方案是否真正带来收益。为什么验证很重要
SQL 优化中最常见的问题之一，是把“理论上可能更快”误认为“实际上更快”。 以下情况都可能导致优化建议无效：- 优化器仍然选择原来的访问路径
- 数据选择性与预期不同
- 新索引成本高于收益
- 重写 SQL 导致额外排序或物化
- 数据库版本或统计信息改变优化结果
- 分布式数据库产生额外数据移动
核心能力
优化前后执行计划对比
比较原始 SQL 与优化 SQL 的执行计划。 重点关注：- Scan 类型变化
- Join 算法变化
- Join 顺序变化
- Sort / Aggregate 变化
- 数据访问量变化
- 分布式数据移动变化
代价对比
比较数据库优化器给出的 Cost 或等价估算指标。 Cost 并不等同于真实执行时间，但可以作为优化候选筛选与自动验证的重要信号。索引验证
判断推荐索引是否：- 被优化器实际使用
- 改变访问路径
- 降低扫描行数
- 降低排序或 Join 成本
重写验证
判断查询重写优化是否真正改善执行策略，而不仅仅是代码形式变化。优化评分
在批量 SQL 治理场景中，可以基于：- Cost 改善幅度
- SQL 执行频率
- SQL 当前成本
- 风险等级
示例
原始 SQL：- 优化器是否从 Full Table Scan 转为 Index Scan？
- Cost 是否下降？
- 预计扫描行数是否明显减少？
- 是否已有等价索引？
- 新索引是否值得承担写入与维护成本？
验证闭环
这使 SQL 优化形成闭环，而不是停留在建议列表。代价是证据，不是绝对真理
数据库 Cost 是优化器内部估算值，并不等于真实耗时。 因此：- Cost 适合用于候选方案比较
- 执行计划结构应与 Cost 一起分析
- 对关键生产 SQL，可进一步结合真实执行数据
- 统计信息不准确时，应谨慎解释 Cost