当试图了解 SQL 语句的执行方式时，有时建议查看解释计划。在解释(理解)解释计划时应该经历什么过程？什么应该脱颖而出，“哦，这工作得很好？”与“哦不，那不对。”
最佳答案
每当我看到完整表扫描不好而索引访问很好的评论时，我都会不寒而栗。全表扫描、索引范围扫描、快速全索引扫描、嵌套循环、合并连接、散列连接等都是简单的访问机制，分析师必须理解这些机制，并结合数据库结构知识和查询目的以便得出任何有意义的结论。
全扫描是读取数据段(表或表(子)分区)的大部分块的最有效方法，虽然它通常可以指示性能问题，但这只是在它是否是实现查询目标的有效机制的上下文中。作为一名数据仓库和 BI 人员，我的第一个性能警告标志是基于索引的访问方法和嵌套循环。
因此，对于如何阅读解释计划的机制，Oracle 文档是一个很好的指南:http://download.oracle.com/docs/cd/B28359_01/server.111/b28274/ex_plan.htm#PFGRF009
也请仔细阅读性能调优指南。
还有一个用于“基数反馈”的谷歌，一种解释计划可用于将查询中各个阶段的基数估计与执行期间遇到的实际基数进行比较的技术。我相信 Wolfgang Breitling 是该方法的作者。
因此，归根结底:了解访问机制。了解数据库。了解查询的意图。避免经验法则。
关于sql - 您如何解释查询的解释计划？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/79266/