读书笔记：白话Oracle索引：给你的数据库查询装上“导航仪”

我们的文章会在微信公众号IT民工的龙马人生和博客网站( www.htz.pw )同步更新 ，欢迎关注收藏，也欢迎大家转载，但是请在文章开始地方标注文章出处，谢谢！
由于博客中有大量代码，通过页面浏览效果更佳。

本文为个人学习《Expert Oracle Database Architecture Techniques and Solutions for High Performance and Productivity（第四版本》一书过程中的笔记与理解分享，仅用于学习与交流，部分内容参考原书观点并结合>实际经验进行整理。若涉及版权问题，请联系删除或沟通处理。也请大家支持购买原版书籍。

白话Oracle索引：给你的数据库查询装上“导航仪”

想象一下，你在一个巨大的图书馆里找一本书。如果书架上的书全是乱放的（我们称之为“堆表”），你就得一排排地挨个找，这要花非常多时间。但如果有索引卡片（也就是数据库索引），告诉你书的具体位置，你就能很快找到它。

数据库里的索引就是这个道理，它能极大加快查询速度。但索引不是越多越好——就像如果你的索引卡片太多，管理这些卡片本身也会变得很麻烦，反而会拖慢新书上架（插入）、旧书信息更新（修改）的速度。

所以，核心难题是：找到“查询速度”和“维护成本”之间的最佳平衡点。

最好在项目一开始设计数据表时，就规划好索引。如果等系统上线后再补救（被动调优），往往会产生很多没用的索引，既占空间又拖慢系统。

---

Oracle提供了哪些类型的“导航仪”？（索引类型）

Oracle数据库提供了多种强大的索引，就像不同用途的导航仪：

1. B树索引 (BTree Index) - 【标准车载导航】

• 最常见、最常用的索引类型，适合绝大多数情况。
• 它的结构是平衡树，能保证无论数据多少，查找任何一条记录的速度都很快（只需几次查找）。
• 注意：这里的“B”指的是“平衡”，而不是“二叉”。

2. 索引组织表 (IOT) - 【内容本身就有序的书】

• 这是一种特殊的表，它本身就是按主键排序存储的，像一本页码顺序和内容顺序一致的书。
• 对于按主键查询的应用（如信息检索、数据分析）效率极高。

3. 降序索引 (Descending Index) - 【支持从大到小查的导航】

• 普通的索引默认是从小到大排序。这个索引允许你从大到小快速查询，比如经常要查“最近10个订单”。

4. 反向键索引 (Reverse Key Index) - 【解决“热点”问题的导航】

• 专门对付“热点块”问题。比如用序列生成ID，ID值总是递增的（1,2,3...），新数据都会挤在索引最后那个块，造成拥堵。
• 这个索引会把键值反转（比如123变成321），把连续的数据打散，让插入均匀分布到各个块，提高并发性能。

5. 位图索引 (Bitmap Index) - 【人口普查员】

• 适合那种值种类很少的列，比如“性别”（只有男/女）、“状态”（只有Y/N/null）。
• 它用一个位图（一串0和1）来表示数据，做统计（比如有多少个“Y”）时速度极快。
• 重要警告：千万不要在OLTP系统（高并发的事务系统，如订单处理）中使用它，因为它会对锁的粒度造成严重影响，导致并发性能急剧下降。它只适用于数据仓库等查询分析型系统。

6. 位图连接索引 (Bitmap Join Index) - 【预先把表连接好的导航】

• 直接把两张表连接后的结果做成一个位图索引。比如经常要按“部门所在地”查“员工数量”，这个索引可以预先算好部门和员工的关系，查询时就不用现场连接表了。
• 同样，有和位图索引一样的警告，不能用于高并发OLTP系统。

7. 函数索引 (Function-based Index) - 【支持模糊地址的导航】

• 普通索引只对原字段有效。如果你经常用函数查询，比如 WHERE UPPER(name) = 'ALICE'（忽略大小写查名字），这个索引就能派上用场。
• 它存储的是函数计算后的结果，所以能极大加速这类查询。

8. 应用域索引 (Application Domain Index) - 【自定义特种导航】

• 这是最高级的玩法，允许你自己开发特定类型的索引，来应对特殊的数据和查询需求，比如Oracle的文本索引(Text Index)用于全文搜索。

---

总结与忠告

选择正确的索引是保证数据库性能的关键。

• 大部分时候，你需要的都是B*树索引这位可靠的老伙计。
• 对于低基数（重复值多）且只读为主的统计分析，考虑位图索引。
• 遇到序列增长导致的热点块问题，看看反向键索引。
• 查询条件经常带函数？函数索引能帮你。
• 切记：索引不是免费的，每增加一个索引，都会给数据的插入、更新和删除操作带来额外的负担。一定要在“加快查询”和“降低写性能”之间做好权衡。

最好的策略就是在设计阶段，根据业务查询需求，精心设计索引，这样才能让你的数据库应用行云流水，而不是等到出了问题再手忙脚乱地补救。

------------------作者介绍-----------------------
姓名：黄廷忠
现就职：Oracle中国高级服务团队
曾就职：OceanBase、云和恩墨、东方龙马等
电话、微信、QQ：18081072613
个人博客: (http://www.htz.pw)
CSDN地址: (https://blog.csdn.net/wwwhtzpw)
博客园地址: (https://www.cnblogs.com/www-htz-pw)