全量及增量行转列

以下两种情况会执行行转列操作：

• 第一种情况：使用DDL语句对部分列创建列索引（对一张已存在的表有分析型需求），此时需要扫描全表数据以创建列索引。
• 第二种情况：在事务操作过程中对涉及到的列执行行转列。

对于全表行转列的情形，使用并行扫描的方式对InnoDB中的Primary Key进行扫描，并依次将所有涉及到的列转换为列存形式，该操作的速度非常快，其基本仅受限于服务器可用的IO吞吐速度和CPU资源。该操作是一个online-DDL过程，不会阻塞在线业务的运行。

在一张表上建立列索引之后，所有的更新事务将会同步更新行存和列存数据，以保证二者的事务一致性。下图演示了开启和关闭IMCI功能的差异性。

• 未开启IMCI功能时，事务对所有行的更新都会先加锁，然后在对数据页进行修改，在事务提交之前会对所有加锁的记录一次性释放锁。
• 开启IMCI功能之后，事务系统会创建一个列存更新缓存，在所有数据页被修改的同时，会记录所涉及到的列存的修改操作，在事务结束并释放锁之前，该缓存会应用到列存系统。
  
  对于一般的OLTP型请求，最后的内存数据页更新只占事务操作过程的很少一部分时间，因此此方法对TP型事务时延的影响非常小。对于操作了非常多的行的大事务，则会直接将其对列索引的更新实时应用到列存存储，但是在事务提交之前不对外可见，也保证了大事务的提交延时增加在一个非常小的时间范围。同时为了更进一步的降低对TP性能的影响，当AP型查询对数据的实时性要求不高时, 列索引支持异步应用对列存的更新操作。

列存存储提供了与行存一样的事务隔离级别。对于每个写操作，RowGroup中的每一行都会记录修改该行的事务编号，而对于DeleteBitMap，每个标记删除操作也会记录该标志位的事务编号。借助写入事务号和删除事务号，AP型查询可以用非常轻量级的方式获得一个全局一致性的快照。