【版权声明】未经博主同意，谢绝转载！（请尊重原创，博主保留追究权）
https://developer.aliyun.com/article/1634956
出自【进步*于辰的博客】参考笔记一，P25.27、P26.28、P30.2；笔记二，P69.5、P70/71。
注：索引是一种数据结构（B树或B+树）。索引的“宏观”表现可以是“一棵树”，或者是树的“一个节点”。而“索引值”指索引的数据部分（见第2.4项，包括
Key column value、rowid），而“索引列值”指记录或数据（即Key column value）。
1、介绍
下图红框处是数据表的rowid，其是每行记录的唯一标识。
从宏观上说，==索引是排序后的 rowid==。其中，排序不是指升序或降序，而是指将rowid按照一定的 数据结构 进行排列。
先说结论：
rowid本身无任何优化查询的功能，索引之所以可以优化查询依赖于数据结构。
基础操作：
# 创建
1、当添加主键或唯一键时，会自动生成索引。
2、create index 索引名 on 表名(字段名);
# 字典
1、user_indexes; # 查询用户所有索引；
2、user_ind_columns; # 查询用户所有索引对应的字段。
这种索引属于主键索引，索引建立在主键字段上。实际上，可以在任何某个或某多个字段上建立索引，并且索引有多种，见下文。
适用场景：
- 数据量大；
- 结果集所包含记录量占数据表记录量的
2% ~ 4%左右； - 经常用作条件或多表连接的字段；
- 所查询字段的记录范围很广；
- 所查询字段包含大量 null，因为索引不包含 null。
不适用场景：
- 数据量小；
- 不常作为条件的字段；
- 频繁更新的字段；
- 索引字段是条件的一部分时。如：
where emp.salary * 2 > 10000，此时索引无效；（原因后续说明） - 条件中包含单行函数时。如：
where round(salary) > 10000。（除“基于函数的索引”外，见下文）
补充：
- 优点：优化查询速度。
- 不足：占用内存；索引数量多时难以维护；降低 DML 时性能。
- 适用场景：当数据量大、不经常进行 DML 且访问频率高时。（对上述阐述的总结）
- 一般情况下，先添加索引，后新增记录；（原因后续说明）
- 当条件中包含
like、in、not in等范围查询时，索引失效。（下文说明）
2、索引优化查询原理
启发自博文《Oracle索引结构》（转发）。
2.1 构建过程
先行说明：
- 下文中，
id是数据表其中一个字段，非主键。- 无论Oracle、MySQL，亦或者其他关系型数据库，索引的数据结构都包括
B树、Hash表这2种。以下以B树为例。
借用那篇博文中的两张图，便于大家理解。
说明：
- 将
rowid和id取出，组成一个类似entry的数据结构（见第3项中的索引结构图），即一条记录对应一个“entry”。n个“entry”（n条记录）组成一块（叶节点）；
注：“entry”即索引，不过其不是entry，下文简述索引细节。这里说的entry，大家以Map.Entry理解就行。 n个块由某个块（茎节点）管理，此节点记录着所管理的n个块的信息，即索引；- 以此类推。。。
- 由某个节点（根节点）管理所有的茎节点。
2.2 关于 B+树
大部分情况下，索引的数据结构不是B树，而是B+树。B+树是由B树改进而成，相同的是，两者都属于平衡多路查找树（关于“平衡多路查找树”，后续补充，大家先注意“多路”两字即可，便于理解上述的索引构建过程）。
不同的是（改进措施）：
- 在
B树中，所有节点都存放 索引 和 数据，因此B树型索引的索引不会重复；而在B+树中，“非叶节点”存放的是所管理节点的信息（即更“高阶”节点的索引），而所有的数据都存放在“叶节点”中，包括“索引列值”和rowid，即索引。因此，所有“非叶节点”的索引值最终一定会全部出现在“叶节点”中（即“非叶节点”中的索引会重复1次）。 - 在
B+树中，会将所有“叶节点”都连接起来，形成“链表”，按索引 升序 排序，这样是为了便于范围查找，而B树不会。
注：便于“范围查找”的原理：程序读取数据库的途径是IO流，对于已建立索引的数据表，一次IO，就是将B树/B+树的一个节点读入内存。若所查找的数据分布在多个节点中（范围查找需要查找多个节点），则需要多次执行IO。因此，B+树的“链表”可以减少IO的次数。
PS：B树型数据结构只有B树和B+树两种，在一些资料中，大家可能会看到B-树，这并不是另一种数据结构。因为B树的英文是B-tree，所以会简称为“B-树”，其实就是B树。
2.3 补充说明
B树高度较低。如：在一个有几百亿条记录的数据表上建立索引，“树”高度不过 20 余层。- 数据库最小单位是块，最小分配单位是区，存放一个段至少需要一个区。（最后这点暂不明其意）
- 为什么索引查找不一定比全表扫描（无索引）效率高？ 全表扫描一次可读多个块，而索引查找一次只能读一个。大部分情况下，索引查找的记录可能分散分布于多个块，即==索引查找的读取次数可能多于全局扫描==。（上文【补充】的第5点就是这种情况，故致使索引失效）
注：以上阐述基于B树，而B+树的其中一个作用就是应对这种情况。2.4 索引结构细节
大家看另1张图。
可见，索引值由Index entry header、Key column length、Key column value（列值，即上文中的“索引列值”）、ROWID组成。
3、关于索引分类
3.1 唯一索引
主键或唯一键创建时自动生成；
手动创建：
create unique index 索引名 on 表名(字段名)
3.2 组合索引
当创建索引时，指定多列，就是组合索引。其中，根据上文【构建过程】，可知组合索引的每一个索引列值都包含组合列的各个数据。
注意： 只有当条件（where）中包含此组合所有或大部分字段时，索引才能生效（后续详述）。
3.3 反向键索引
反转索引列值的每个字节，从而实现索引值的均匀分配，==避免B+树不平衡==。（注：“不平衡”是指某个/某些分支较其他同高度分支较长，致使分支“倾斜”的情况）
常用宇连续增长、且索引列值前段相同的字段。如：索引列值为1001、 1002、1003，经反向键索引转化后变为1001、 2001、3001。
手动创建：
create index 索引名 on 表名(字段名) reverse
3.4 位图索引
适合创建于“低基数”的字段，如：性别、国家编号。（注：“低基数”指取值固定或取值范围很小、且==不经常更新==）
上文阐述：“索引值由索引列值（记录/数据）和rowid组成”，而位图索引不是。
位图索引不直接存储rowid，而是存储字节位与rowid的映射，目的是==减少空间占用==。
因此，位图索引适用于数据仓库，不适用于OLTP（关于OLTP，后续说明）。
手动创建：create bitmap index 索引名 on 表名(字段名)。
3.5 基于函数的索引
指基于1/n个字段上的函数或表达式创建的索引。简言之，在创建此类索引时，使用了表达式或函数。
限制：表达式中不能使用聚合函数（如：count、max、sum），比较常用的是单行函数；字段类型不能是lob（clob、blob）；且当前用户必须拥有query rewrite权限。
示例：
需求：查询用户名，用“基于函数的索引”进行优化。
语句：`... where upper(user_name) = ‘xx’ ...`。
手动创建：`create index 索引名 on 表名(upper(字段名))`。
最后
本文是“纯阐述”，0 示例，这样可能有点不严谨。因此，本文的目的是为了让大家对Oracle索引所实现的性能优化原理、以及分类有一个大致的了解。
本文完结。
