摘要:

之前在处理的mysql列存储, 与mysql/innodb有显著的差异。

作为列存储, 相比于行存, 获取属性不需要提取一整行, 有磁盘IO上的优势。

但是这主要表现在全表扫描上面, 本文分析相比mysql/innodb更多的不足。

mysql/innodb的查询优化器:

一. 核心在于索引

1. 核心在于索引，无论是主键索引还是二级索引, 全文索引
2. mysql的查询优化器是基于代价的, 代价的数据来自于所谓的file也就是handler引擎的接口
3. 基于代价的计算对于存在主键和非主键的计算公式自然是不同的,

二. 在查询优化阶段便利用索引开始执行查询

1. 如果从查询优化的角度, 这也合理,　毕竟利用索引直接求取出子查询的结果，可以在真正执行时仅保留需要继续查询的部分
2. 这就将索引的重要性更为凸显
3. 同时也将执行阶段和查询优化阶段的边界做的不是严格的划分，看起来不是那么清晰

三. innodb引擎仅提供接口, 由mysql/sql层负责调度

1. 不但优化流程由sql层负责, 执行流程也由sql层负责
2. innodb引擎实现一系列引擎handler的接口, 由sql层负责调用
3. sql层在查询优化过程中填充QEP_TAB结构体, 内部的回调函数是具体的调用流程

mysql列存储引擎:

一. 仅保留一部分mysql/sql层的优化

1. 保留了等值谓词消除部分
2. 但是更多的sql层优化被屏蔽
3. 这么做的原因是和列存引擎的功能欠缺有关, 功能并不能完整支持sql优化器优化后的查询树

二. 直接替代了mysql/s