概述
时至2020年，市面上基本所有的关系型数据库都实现了inplace方式创建与添加索引，这是业务的需求，也是科技发展的迭代。
本文主要讲的是OceanBase2.x的索引创建与添加原理。
索引构建方式
以MySQL为例。MySQL在5.6版本后支持了inplace方式添加索引。inplace顾名思义是就地升级的意思，在执行alter table add index语句时，会给表的元数据加锁，遍历聚簇索引的相关记录后，释放锁，然后，把新事物中的新索引表的数据写入到row log中，同时等待未提交事物提交完成后，开始索引构建，最后将主表的相关索引列在内存中排序整理后，将前面记录的row log应用到最终的索引表中，这个阶段也要锁定一次元数据。构建完成后，释放元数据锁，索引设置可写，进而使优化器可以使用该索引，提供查询使用。
与MySQL不同的是，分布式的数据分布和请求执行可能是分布在多台机器上的，所以在索引构建方式上也是有所不同的。
OceanBase索引构建
总体架构
如图所示，OceanBase一般由三个逻辑zone组成，一个逻辑zone包括一个或多个OBServer。
每个zone中会包含一个RootServer的节点，该节点负责管理集群的元数据和路由信息，其中，元数据是按照多版本方式管理的。每个节点又有多个partition，这些partition是管理数据的最小单位，一张表包含一个或多个分区，每个partition的数据又可以在其他zone的节点上保留有一个完整的数据副本。
索引分区
由于partition是作为最小管理单元形式存在的，所以，索引也有可能和主表在同一partition，也有可能不在同一个partition上，这也就意味着索引表可能和主表不在同一台机器上。
局部索引：索引表的字段数据只与主表的单一分区的数据做关联，保持一对一的关系
全局索引：索引表的字段数据把主表的所有分区数据看作一个整体，一个键值可能会映射到多个分区中去，其中，又分为：
1、全局分区索引：对索引表进行分区，索引表的一个键值可能映射到多个分区，保持多对多的关系。
2、全局非分区索引：索引表不进行分区，索引表的一个键值可能映射到多个分区，保持一对多的关系。
索引构建
在OceanBase2.x中，索引构建有四个阶段：准备、构建、拷贝、收尾。
如何保证多服务器下的数据一致性：将DDL语句通过obproxy发送给其中的一台RootServer，在一个节点上执行完成后，后续由其他节点在拷贝阶段直接从rs上拷贝数据到本节点。
准备阶段
1、生成索引表的元数据信息，将索引表设置为只写状态，将索引表构建期间的事物数据直接写入到Memtable中，后续构建无需再写入这部分数据。
2、等所有事物结束后，获取当前快照点。
构建阶段
基于主表快照点扫描出索引表所需数据，并按照索引列排序规则生成索引表基线SSTable数据。
1、局部索引构建：由于和主表在同一个分区，那么数据的流动也只存在于本机。
2、全局索引构建：由于和主表不在同一个分区，可能又存在于多台observer上，所以，构建索引的过程，也是一个分布式排序的过程。OceanBase在构建过程中更注重容灾和恢复，因此，在构建过程中实现了中间结果持久化，在构建过程中出现宕机时，只需要选择其他机器重新执行相关任务。
由于分布式排序对io影响比较大，所以会基于用户IO请求来限速，当用户请求的IO响应时间超过一定阈值时，会自动限制构建过程中IOPS。
在构建过程中，可能会遇到合并的相关状况，导致主表的和索引表的快照版本各不相同。所以每个基线SStable都有一个自己的版本号，即使版本号不同，也会构建成功。
拷贝阶段
由于构建阶段非常耗时，所以只在单副本上构建索引表，其他副本从构建好的副本拷贝数据。OceanBase可以基于partition级别实现并行化，每个分区会按照数据量切分成多个任务，由多个线程批量地执行任务。
收尾阶段
收尾阶段需要进行数据校验和索引生效。
1、数据校验：目的是为了保证索引表和主表的数据是一致的，根据主要的列校验和索引表的列校验进行比对。对于唯一索引，由于构建过程中不会与SStable进行合并，所以校验可能不完整，因此，在索引表基线数据构建和拷贝完成后，对唯一索引进行唯一校验。
2、当数据校验通过时，将索引表设置为可读写状态，进而优化器可以使用新索引来加速查询，当校验不通过时，会讲索引表设置为不可用状态。
