当尝试了解 SQL 语句如何执行时，有时建议查看解释计划。在解释（理解）解释计划时应该经历什么过程？什么应该脱颖而出，“哦，这工作得很好？”与“哦，不，那是不对的”。
每当我看到关于全表扫描不好而索引访问很好的评论时，我都会感到不寒而栗。全表扫描、索引范围扫描、快速全索引扫描、嵌套循环、合并联接、散列联接等只是分析人员必须理解的访问机制，并结合数据库结构和查询目的的知识。以便得出任何有意义的结论。
完全扫描只是读取数据段（表或表（子）分区）的大部分块的最有效方法，虽然它通常可以指示性能问题，但这仅在上下文中它是否是实现查询目标的有效机制。作为一名数据仓库和 BI 人员，我的第一个性能警告标志是基于索引的访问方法和嵌套循环。
因此，对于如何阅读解释计划的机制，Oracle 文档是一个很好的指南：http://download.oracle.com/docs/cd/B28359_01/server.111/b28274/ex_plan.htm#PFGRF009 http://download.oracle.com/docs/cd/B28359_01/server.111/b28274/ex_plan.htm#PFGRF009
还请仔细阅读《性能调优指南》。
还可以在谷歌上搜索“基数反馈”，这是一种可以使用解释计划将查询中各个阶段的基数估计与执行过程中经历的实际基数进行比较的技术。我相信沃尔夫冈·百年灵（Wolfgang Breitling）是该方法的作者。
因此，底线是：了解访问机制。了解数据库。理解查询的意图。避免经验法则。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
