说说Oracle数据库索引到底咋实现的，还有那些优化小技巧分享

说到Oracle数据库的索引,你可以把它想象成一本书最前面的目录，如果没有目录，你想找某个章节的内容，就得一页一页地翻，这就是数据库的“全表扫描”，非常慢，而有了目录（索引），你就能快速定位到内容大概在哪一页，然后直接翻过去，速度就快多了。

Oracle索引的核心实现：B树结构

Oracle最常用、最经典的索引类型是B树索引（Balance Tree，平衡树），你可以把它想象成一棵倒过来的树，它有根、有枝、有叶。

• 根节点和分支节点：就像目录的大的分类，你想找“数据库优化”这个词，根节点可能告诉你，这个词的首字母是“S”，所以你应该去“S”开头的分支节点找，分支节点会进一步细化，告诉你“数据库”这个词在哪个更细的分支上，这些节点里不存放实际的数据，只存放“路标”，指引你下一步该往哪里走。
• 叶子节点：这是索引树最底层的节点，也是真正干活的部分，每个叶子节点里，会整齐地存放着索引列的值（比如你索引的是“姓名”列，这里就存着“张三”、“李四”），并且每个索引值都对应着一个“ROWID”，这个ROWID是Oracle数据库给每行数据分配的一个唯一、精确的“地址”，它直接告诉你这行数据存储在硬盘的哪个文件、哪个块、哪一行，找到叶子节点，就相当于找到了这个精确的地址。

当你用索引查询时,过程是这样的：从树的根部开始，根据你要找的值，一层一层地往下找，就像查字典一样，最终到达叶子节点，拿到ROWID，然后数据库根据这个地址，直接去硬盘上把那一行数据“拿”出来，整个过程非常高效，因为数据库要扫描的数据量大大减少了。

除了B树，还有哪些常见的索引？

1. 位图索引：这个适合用在那些值种类很少的列上，性别”列（只有男、女），“状态”列（只有激活、未激活、注销），它不像B树那样存一个个的值，而是用一串0和1的位图来标记，它会给表中的每一行编个号，然后为“男”这个值创建一个位图，如果第1、3、5行是男性，那么这个位图就是“101010...”，当进行多条件查询时（比如查“北京的女性”），位图索引可以通过直接的“与或非”位运算来合并结果，速度极快，但注意，它不适合频繁更新的表，因为锁的粒度很大。
2. 函数索引：有时候我们会在查询条件里对列用函数，WHERE UPPER(name) = 'ZHANG SAN'，这时，即使name列上有普通B树索引，也用不上，因为索引里存的是小写的“zhang san”，而不是大写的，为了解决这个问题，你可以直接创建一个函数索引，索引的不是name列本身，而是UPPER(name)这个函数的结果，这样查询时，就能直接用上索引了。

一些实用的优化小技巧

1. 考虑索引的代价：索引不是越多越好，每创建一个索引，就像多写了一本目录，当你往表里增、删、改数据时，数据库不仅要改表本身，还要去更新所有相关的索引（更新所有“目录”），这会降低写入速度，要在查询速度和写入速度之间做权衡，对于几乎不查询，总是批量插入数据的表，索引反而可能是负担。
2. 关注索引的“区分度”：尽量在值种类多的列上建索引，身份证号”列，几乎每个值都不同，区分度极高，索引效果就好，而在“性别”列上建普通B树索引，因为只有两种值，你查“男”的时候，还是要从索引里找出所有“男”的ROWID，再去表里取数据，效果可能并不比全表扫描好多少，这种列更适合位图索引。
3. 利用复合索引的“最左前缀”原则：如果你经常同时按“城市”和“姓名”查询，可以创建一个复合索引（城市, 姓名），这个索引的好处是，当你只查“城市”时，它也能被用上，如果你只查“姓名”，而没有“城市”这个条件，这个索引就用不上了，这就像电话簿是按（姓, 名）排序的，你只知道名不知道姓，就很难查。
4. 避免在索引列上做计算：WHERE price * 2 > 100 这样的条件，索引price列是用不上的，因为索引里存的是原始价格，而不是价格乘以2后的结果，应该尽量把计算移到等号另一边，写成 WHERE price > 50。
5. 定期审视索引：数据库运行一段时间后，由于频繁的增删改，索引可能会产生很多碎片，变得不再“平衡”和紧凑，影响效率，Oracle提供了像 ALTER INDEX ... REBUILD 这样的命令来重建索引，整理碎片，这就像定期整理你的书柜，让目录保持清晰。
6. 理解“索引覆盖扫描”：如果你的查询只需要返回索引列中包含的数据，比如你有一个索引是（姓名，电话），而你查询 SELECT 电话 FROM 用户 WHERE 姓名 = '张三'，那么数据库聪明到可以不用根据ROWID回表去取数据了，因为它需要的数据（电话）在索引的叶子节点上已经全部拿到了，这会极大地提升查询速度。

Oracle索引的核心就是用空间（额外存储索引结构）换时间（极快的查询速度），用好它的关键在于理解其工作原理（B树等），并根据你实际的数据特点和查询习惯，来设计和维护最合适的索引策略。