必须借助DRAM的低读写延时来弥补列式存储更新效率低的问题。因此在低延时在线事务处理和高性能实时数据分析两大前提下，行列混合存储结合内存计算是唯一方案。
MySQL的实现架构在执行复杂查询时性能差有多个方面的原因，对比专用的OLAP系统，其性能瓶颈体现多个方面：
MySQL的SQL执行引擎基于流式迭代器模型(Volcano Iterator)实现,
在PolarDB的存储引擎（InnoDB)上新增对列式索引（Columnar Index）的支持，用户可以选择通过DDL将一张表的全部列或者部分列创建为列索引，列索引采用列压缩存储，其存储空间消耗会远小于行存格式。默认列索引会全部常驻内存以实现最大化分析性能，但是当内存不够时也支持将其持久化到共享存储上。
在PolarDB的SQL执行器层，我们重写了一套面向列存的执行器引擎框架(Column-oriented), 该执行器框架充分利用列式存储的优势，如以4096行的一个Batch为单位访问存储层的数据，使用SIMD指令提升CPU单核心处理数据的吞吐，所有关键算子均支持并行执行。在列式存储上，新的执行器对比MySQL原有的行存执行器性有几个数量级的性能提升。
PolarDB的Optimizer会根据行存的Plan,计算得出一个面向行存的执行Cost。如果此Cost超过一定阈值，则会尝试下推到IMCI执行器使用IMCI_Plan进行执行。
采用了与Postgres类似表达式实现方法：在SQL编译及优化阶段，IMCI的表达式以一个树形结构来存储(与现有行式迭代器模型的表现方法类似)，但是在执行之前会对该表达式树进行一个后序遍历，将其转换为一维数组来存储，在后续计算时只需要遍历该一维数组结构即可以完成运算。
列存数据默认压缩格式存储在磁盘上，并可以使用In-Memory Columbia Store Area来做缓存加速并加速查询，传统的行格式依然保存在BufferPool中供OLTP性负载使用。
所有事务的增删改操作都会实时反应到列存存储上，保证事务级别的数据一致性。
满足OLTP业务的需求是第一优先的，因此增加列存支持不能对TP性能太大影响。这要求我们维护列存必须足够轻量，必要时需要牺牲AP性能保TP性能。
列存RowGroup中每新写入一行都会分配一个RowID用作定位，属于一行的所有列都可以用该RowID计算定位，同时系统维护PK到RowID的映射索引，以支持后续的删除和修改操作。
列存的设计无需考虑事务并发对数据的修改, 数据的unique check等问题，这些问题在行存系统中已经被解决，而这些问题对ClickHouse等单独的列存引擎是非常难以处理的。
