Oracle 索引不仅有 B-tree，还包括 Bitmap、Function-Based、Reverse Key、Domain、Invisible 和分区索引等。索引设计要服务 SQL 访问路径、约束、并发和维护成本。

1. 学习目标与定位

维度	内容
难度层级	进阶到调优
核心目标	从底层运行链路理解本篇主题，能把概念、SQL、指标、故障和工程取舍连起来
适合人群	开发人员关注访问路径和约束；运维人员关注索引维护、统计信息、空间和计划稳定。

2. 核心概念总览

Oracle索引结构与设计
├─ B-tree Index
├─ Bitmap Index
├─ Unique Index
├─ Function-Based Index
├─ Reverse Key Index
├─ Invisible Index
├─ Local Index
├─ Global Index
└─ Index Maintenance

这张图只用来定位本章范围。正文不会把每个词机械拆成固定问答，而是按 Oracle 的真实运行机制解释它们之间如何协作、在哪里影响开发、在哪里影响运维。

3. 底层原理详解

B-tree 索引通过根块、分支块、叶子块定位 ROWID，适合高选择性等值和范围查询。索引不是只为 SELECT 服务，唯一索引还承担约束，外键索引影响并发，分区索引影响维护窗口。

索引设计必须结合 SQL 谓词、连接、排序、聚合和数据分布。列顺序、选择性、聚簇因子、函数表达式、NULL 值和隐式转换都会影响索引使用效果。

索引也有成本。每次 DML 都要维护相关索引，索引越多写入越慢，空间越大，统计信息越复杂。OLTP 和数据仓库的索引策略完全不同。

4. 关键机制拆解

4.1. B-tree、唯一索引和访问路径

B-tree 叶子块按键值排序，适合范围扫描和排序消除。唯一索引既可提升查询，也可强制业务唯一性。复合索引要把高频谓词、等值条件、范围条件和排序需求一起考虑。

索引能否使用，不只看列是否存在，还要看谓词形式。对索引列做函数、隐式转换或低选择性过滤，可能让优化器选择全表扫描。

4.2. Bitmap、函数索引和反向键索引

Bitmap 索引适合低基数、少更新、分析型场景，不适合高并发 OLTP 更新。Function-Based Index 可以支持表达式谓词，但要求 SQL 表达式一致且统计信息正确。Reverse Key Index 可缓解递增键右侧热点，但会牺牲范围扫描能力。

这些索引不是高级就更好。每一种都对应明确问题，使用前要写清楚解决的等待、计划或维护目标。

4.3. 本地索引、全局索引和分区维护

Local Index 与表分区一一对应，分区维护更容易；Global Index 跨分区维护，某些分区操作会让它失效或需要维护。

大表分区环境下，索引设计必须和归档、分区交换、在线维护结合。否则一次分区删除可能引发全局索引维护风暴。

4.4. 索引维护与失效治理

索引会膨胀、失效、统计信息过期，也可能与其他索引重复。Invisible Index 适合灰度验证删除索引的影响。

运维人员要定期检查索引使用、大小、BLEVEL、聚簇因子和重复索引。开发人员新增索引必须说明受益 SQL 和写入成本。

5. 功能模块细节补充

本节围绕概念图中的模块逐个补充底层细节，重点讲它们在 Oracle 运行链路中的位置和相互关系，而不是按固定角色模板拆分。

5.1. B-tree Index

B-tree Index 是访问路径和维护成本之间的取舍。索引能减少扫描、支持约束和排序，但会增加 DML 成本、空间消耗和统计信息复杂度；不同索引类型必须匹配数据分布、并发模型和维护窗口。

5.2. Bitmap Index

Bitmap Index 是访问路径和维护成本之间的取舍。索引能减少扫描、支持约束和排序，但会增加 DML 成本、空间消耗和统计信息复杂度；不同索引类型必须匹配数据分布、并发模型和维护窗口。

5.3. Unique Index

Unique Index 是访问路径和维护成本之间的取舍。索引能减少扫描、支持约束和排序，但会增加 DML 成本、空间消耗和统计信息复杂度；不同索引类型必须匹配数据分布、并发模型和维护窗口。

5.4. Function-Based Index

Function-Based Index 属于 PL/SQL 过程化运行环境。PL/SQL 靠近数据，适合批处理和封装，但也可能隐藏事务提交、异常吞噬、包状态和依赖失效；发布时要同时检查编译、权限、依赖和回滚方案。

5.5. Reverse Key Index

Reverse Key Index 是访问路径和维护成本之间的取舍。索引能减少扫描、支持约束和排序，但会增加 DML 成本、空间消耗和统计信息复杂度；不同索引类型必须匹配数据分布、并发模型和维护窗口。

5.6. Invisible Index

Invisible Index 是访问路径和维护成本之间的取舍。索引能减少扫描、支持约束和排序，但会增加 DML 成本、空间消耗和统计信息复杂度；不同索引类型必须匹配数据分布、并发模型和维护窗口。

5.7. Local Index

Local Index 是访问路径和维护成本之间的取舍。索引能减少扫描、支持约束和排序，但会增加 DML 成本、空间消耗和统计信息复杂度；不同索引类型必须匹配数据分布、并发模型和维护窗口。

5.8. Global Index

Global Index 是访问路径和维护成本之间的取舍。索引能减少扫描、支持约束和排序，但会增加 DML 成本、空间消耗和统计信息复杂度；不同索引类型必须匹配数据分布、并发模型和维护窗口。

5.9. Index Maintenance

Index Maintenance 是访问路径和维护成本之间的取舍。索引能减少扫描、支持约束和排序，但会增加 DML 成本、空间消耗和统计信息复杂度；不同索引类型必须匹配数据分布、并发模型和维护窗口。

6. 开发人员重点提醒

• 索引设计从 SQL 谓词和业务约束出发，不从字段清单出发。
• 新增索引要评估写入成本和重复性。
• 函数索引、Bitmap 索引、反向键索引必须说明适用场景。

7. 运维人员重点提醒

• 维护索引统计信息，监控索引大小和失效状态。
• 分区维护前评估全局索引影响。
• 用 Invisible Index 验证索引下线风险。

8. 典型问题与排查

• 索引存在但不用：检查隐式转换、函数谓词、统计信息和选择性。
• 写入变慢：检查索引数量和热点索引块。
• 分区操作后计划异常：检查全局索引状态和统计信息。

9. 实践建议与检查清单

• 核心 SQL 有索引设计说明
• 重复索引已治理
• Bitmap 不用于高并发写
• 分区索引策略明确
• 索引下线有灰度验证

10. 阶段小结

本篇的学习重点不是记住术语，而是能把底层机制、业务语义和生产证据连起来。读完本篇后，应该能解释关键组件如何协作、常见问题为什么发生、开发侧如何避免制造风险、运维侧如何用指标和日志把问题定位到具体链路。