OB 中索引的存储方式
根据文档库中的信息，OceanBase（OB）数据库中索引的存储机制具有以下特点：
1. 存储结构与数据表类似
在 OceanBase 数据库中，索引表的存储结构与普通数据表相似，其数据也是存储在宏块（macro block）和微块（micro block） 的结构中。
- 每个索引在内部拥有独立的 Table Store。
- 在每个 Table Store 中包含多个 SSTable 和 MemTable。
- MemTable：存储于内存中，用于存储动态数据，支持读写操作，采用 B+树结构。
- SSTable：存储于磁盘中，用于存储静态数据，只读，采用宏块结构。
最终的数据行是通过将 MemTable 和 SSTable 中的数据行进行融合而得到的完整数据行。
参考链接：数据存储概述
2. 聚集索引模型（Index-Organized Table）
OceanBase 使用的是聚集索引表模型（Index-Organized Table, IOT），这意味着：
- 主键作为聚簇索引，数据按照主键顺序存储和排序。
- 数据与索引合二为一，主键不存在额外的空间开销。
- 插入数据时会按主键顺序插入到表中。
此外，在二级索引（非主键索引）的每一行中，除了用户指定的索引列外，还会自动存储主表的主键列，以便在查询时进行“回表”操作（即通过索引找到主键，再根据主键查找完整数据）。
3. 局部索引与全局索引的存储差异
OceanBase 支持两种主要类型的索引：局部索引（Local Index） 和 全局索引（Global Index），它们在存储上有明显区别：
| 类型 | 存储特性 |
|---|---|
| 局部索引 | 索引数据与主表绑定在同一分区（partition）内，每个分区有独立的索引数据，便于维护和管理。 |
| 全局索引 | 索引数据独立于主表分区分布，跨所有分区统一组织，适用于需要全局快速检索的场景。但在创建时可能占用大量临时空间，尤其在大表上构建时需注意资源限制。 |
注意：V3.x 版本中全局索引构建使用临时文件，受 TmpPageCache 内存限制（默认上限为 15GB），若超过约 210 万个宏块可能触发错误；V4.x 版本该限制调整为租户内存的 70%。
4. 列存索引支持
OceanBase 还支持将索引以列存格式存储，适用于分析型查询场景：
- 创建表或索引时可指定存储格式为列存。
- 索引本身也是一张表，因此可以像普通表一样设置为列存模式，提升聚合查询性能。
参考链接：索引简介
总结
OceanBase 中索引的存储具备以下核心特征：
- 使用 MemTable + SSTable 架构，分别管理内存与磁盘数据；
- 基于聚集索引模型，二级索引包含主键用于回表；
- 支持局部索引与全局索引，存储策略不同，影响性能与资源消耗；
- 支持列存索引，优化分析类查询；
- 大表建索引需关注临时空间与内存限制，合理规划分区策略。
如需进一步诊断索引创建过程，可使用 obdiag 工具预估空间需求或查看执行进度。