写在前面：小编的话
从大量行中查找少量行，一定会使用索引吗？那可未必。例如，从10000行中查找90行，优化器可能会选择全部扫描；而从10000行中查找1000行时，优化器可能会选择索引。为什么会这样，请大家从视频中寻找答案。
在正式上课之前，我们还是要强调一下如何学习这些课程。我们做的最主要的工作是将Dev Gym上的视频翻译为中文。实际上每一节课包括4部分：
1）看我们翻译的视频，每一集只有几分钟。
2）上Live SQL做配套练习
3）小测验（选择题）
4）进一步学习（参考资料）
这4部分都是精心设计的，特别是第2和3部分，非常有助于对课程内容的理解，而且由于原网站有完整的评分积分，因此我们希望您在看完视频后，仍回到Dev Gym（https://devgym.oracle.com/）网站完成练习和测验，而且最终可以得到结业证书。点击文末“原文链接”可访问原课程页面。
以下为开发者性能课的课程设置：
第1课: 如何解读执行计划
第2课: 什么是数据库统计信息？
第3课: 我的查询做了多少工作？
第4课: 如何创建索引
第5课: 为什么我的查询不使用索引？<- 我们在这里
第6课: 如何使用物化视图快速汇总数据
第7课: 联接如何工作？
第8课: 如何更快地插入、更新和删除
第9课: 如何查找慢 SQL
好了，下面正式开始上课。
Oracle开发者性能第5课：为什么我的查询不使用索引？
写在后面：小编的话
通过此视频，大家应该更深刻的理解了优化器在何时会选择索引或全表扫描。当行的物理顺序与索引的逻辑顺序越接近，该索引就越有效。由于Oracle数据库中最小的I/O单元是数据块，指向同一数据库块的连续索引项越多，在一个I/O中获取的行就越多。因此，索引就越有效。在确定索引的效率时，重要的是I/O操作的数量（访问数据库的次数），而不是访问多少行！
优化器其实并不知道逻辑顺序和物理顺序的匹配程度，它使用聚集因子（clustering factor）进行估计。TABLE_CACHED_BLOCKS参数可以改进优化器所认为的聚合度，改进实际的聚合度需要对表重新进行物理组织。这可以借助临时表导出导入实现。另一种更轻量级的方法则是属性聚集（Attribute Clustering）。
今天的概念比较抽象，大家可以借助本课程的配套练习来促进理解，也可以参见小编的实验笔记(1)。
好了，今天的课程就到这里，祝大家学习愉快！
参考链接：
(1) https://blog.csdn.net/stevensxiao/article/details/121043980
编辑，字幕翻译：萧宇
字幕制作&版式设计：Barbara Huang
