gydtep

Plan转换的方法简单直接，只需要遍历这个执行计划树，将 mysql 优化后的 AST 转换成IMCI 以 relation operator 位节点的树状结构即可，是一个比较直接的翻译过程。

gydtep

在PolarDB中除了有原生MySQL的行存串行执行，还有能够发挥多核计算能力的基于行存的Paralle Query功能。因此实际优化器会在1)行存串行执行，2）行存Paralle Query 3)IMCI 三个选项之中选择。在目前的迭代阶段，优化器按如下的流程操作：

gydtep

执行SQL的Parse过程并生成LogicalPlan，然后调用MySQL原生优化器按照执行一定优化操作，如join order调整等。同时该阶段获得的逻辑执行计划会转给IMCI的执行计划编译模块,尝试生成一个列存的执行计划(此处可能会被白名单拦截并fallback回行存）。

gydtep

有行存和列存两套执行引擎的存在，优化器在选择执行计划时有了更多的选择，其可以对比行存执行计划的Cost和列存执行计划的Cost，并使用代价最低的那个执行计划.

gydtep

在数据编码格式上，实现为二级索引的列存可以和其他行存索引使用完全一样的内格式，直接内存拷贝即可，不需要考虑charset和collation等信息，这对上层执行器也是完全透明的。

gydtep

二级索引操作非常灵活，可以在建表时即指定索引所包含的列，也可以后续通过DDL语句对一个二级索引中包含的列进行增加或者删除操作。

gydtep

行转列操作在两种情况下会发生，第一种情况是使用DDL语句对部分列创建列索引(一般是业务对一个已有的表有新增分析型需求)，此时需要扫描全表数据以创建列索引。另一种情况是在事务操作过程中对于涉及到的列实时行专列。

gydtep

第二种方式，RW支持OLTP型负载，并启动一个AP型RO开启行列混合存储以支持查询，此种部署模式下CPU资源可以实现100%隔离，同时该AP型RO节点上的内存可以100%分配给列存存储和执行器。

gydtep

来服务不同的查询负载是一个易于实施的方案。典型的如TiDB，其从TiDB4.0开始，在一个Raft Group中的其中一个副本上，使用列式存储(TiFlash)来响应AP型负载, 并通过TiDB的智能路由功能来自动选取数据来源。

gydtep

这个架构在工程实现上依赖大量深层次的函数嵌套及虚函数调用，在处理海量数据时，这种架构会影响现代CPU流水线的pipline效率，导致CPU Cache效率低下。