gydtep

支持行列混合执行的优化器框架，该优化器框架会根据下发的SQL是否能在列索引上执行覆盖查询，并且其所依赖的的函数及算子能被列式执行器所支持来决定是否启动列式执行。优化器会同时对行存执行计划和列存执行计划做代价估算，并选中代价交代的执行计划。

gydtep

在PolarDB的SQL执行器层，我们重写了一套面向列存的执行器引擎框架(Column-oriented), 该执行器框架充分利用列式存储的优势，如以4096行的一个Batch为单位访问存储层的数据，使用SIMD指令提升CPU单核心处理数据的吞吐，所有关键算子均支持并行执行。在列式存储上，新的执行器对比MySQL原有的行存执行器性有几个数量级的性能提升。

gydtep

几个关键关键技术结合使得PolarDB成为了一个真正的HTAP数据库系统，其在大数据量上运行复杂查询的性能可以与Oracle/SQL Server等业界最顶尖的商用数据库系统处在同一水平。

gydtep

Plan转换的目的是将MySQL的原生逻辑执行计划表示方式AST转换为IMCI的Logical Plan。在生成IMCI的Logical Plan之后，会经过一轮Optimize过程，生成Physical Plan。

gydtep

兼顾行列混合执行的优化器

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

gydtep

PolarDB的Optimizer会根据行存的Plan,计算得出一个面向行存的执行Cost。如果此Cost超过一定阈值，则会尝试下推到IMCI执行器使用IMCI_Plan进行执行。

gydtep

包括当前系统可用的CPU/Memory/IO资源, 目前已经调度和在排队的任务信息, 统计信息, query 的复杂程度, 用户可配置的参数等。根据这些数据计算出一个推荐的DOP值给算子, 而一个算子内部会使用相同的DOP。同时DOP也支持用户使用Hint的方式进行设定。

gydtep

向量化执行解决了单核执行效率的问题，而并行执行突破了单核的计算瓶颈。二者结合使得IMCI执行速度相比传统MySQL行式执行有了数量级的速度提升。

gydtep

AP型场景，SQL中经常会包含很多涉及到一个或者多个值/运算符/函数组成的计算过程，这都是属于表达式计算的范畴。表达式的求值是一个计算密集型的任务，因此表达式的计算效率是影响整体性能的一个关键的因素。

gydtep

在列存格式下，由于每一列的数据都单独顺序存储，涉及到某一个特定列上的表达式计算过程都可以批量进行。对每一个计算表达式，其输入和输出都以Batch为单位，在Batch的处理模式下，计算过程可以使用SIMD指令进行加速。新表达式系统有两项关键优化：