人大金仓KingbaseES Create Index Concurrently 过程探究

我们知道Oracle 可以通过create index online 在线创建索引，而不影响其他会话修改数据，但Oracle 实际在online 创建索引的最后一步，实际还是需要进行锁升级，申请表级的S锁，因此，最后还是有可能堵塞其他会话。而KingbaseES 的两阶段创建索引的机制，则不会对增删改操作有任何影响。以下我们通过观察创建索引过程中会话持有锁及等待的情况，来看下整个过程。

一、KingbaseES 非 Concurrently 创建索引

过程及锁申请如下：

可以看到，正常创建索引的过程需要一直持有 ShareLock 锁，而 ShareLock 与 RowExclusiveLock 冲突，增删改操作无法进行。

二、KingbaseES 以 Concurrently 创建索引

过程及锁持有如下：

注意点：

1. 会话A 模拟了两次事务（这两次事务间隔时间很长），主要是为了验证 concurrently 创建索引的两次读取数据的过程。

2. 会话A 在结束第1个事务后，会话B 才能开始扫描表（所有create index 开始时活动事务结束后），并建立索引。

3. 会话 A 在结束第1 个事务后，立即开启事务2 ， 此时 会话B 才开始建索引，也就是先于 B （在会话B 需要取得snapshot2前），这样会话B 又得等待。

4. 可以看到，在创建过程中会话B 的virtualtransaction 会变动（两个值）

在并发索引构建中，需要在两个虚拟事务中发生两次表扫描。在每一次表扫描之前，索引构建必须等待已经修改了 表的现有事务终止。在第二次扫描之后，索引构建必须等待任何持有早于第二次扫描的快照的事务终止。然后该索引最终能被标记为准备好使用，并且CREATE INDEX命令终止。 不过即便那样，该索引也不是立刻可以用于查询：在最坏的情况下，只要早于索引构建开始时存在的事务存在，该索引就无法使用。

具体阶段如下：

5. 开启 virtualtransaction1，拿到当前snapshot1。

6. 扫描A表前，等待所有snapshot1前所有修改过A表的事务结束。

7. 扫描A表，并建立索引。

8. 结束 virtualtransaction1。

9. 开启 virtualtransaction2，拿到当前 snapshot2。

10. 再次扫描A表前，等待snapshot2前所有修改过A表的事务结束。

11. 在snapshot2之后启动的事务对A表执行的DML，会修改索引。

12. 再次扫描A 表，根据xmin or xmax ，在snapshot1到snapshot2之间变更的记录，合并到索引。

13. 上一步更新索引结束后，等待任何持有早于第二次扫描的快照的事务结束（比如某repeatable read事务读取了该表 ）。

14. 结束索引创建。索引可见。