极速查询的单表查询
StarRocks 在极速查询方面上做了很多，下面着重介绍四点：
1）向量化执行：StarRocks 实现了从存储层到查询层的全面向量化执行，这是 StarRocks 速度优势的基础。向量化执行充分发挥了 CPU 的处理能力。
全面向量化引擎按照列式的方式组织和处理数据。StarRocks 的数据存储、内存中数据的组织方式，以及 SQL 算子的计算方式，都是列式实现的。按列的数据组织也会更加充分利用 CPU 的 Cache，按列计算会有更少的虚函数调用以及更少的分支判断，从而获得更加充分的 CPU 指令流水。
另一方面，StarRocks 的全面向量化引擎通过向量化算法充分利用了 CPU 提供的 SIMD 指令。这样 StarRocks 可以用更少的指令数目，完成更多的数据操作。经过标准测试集的验证，StarRocks 的全面向量化引擎可以将执行算子的性能，整体提升 3-10 倍。
2）物化视图加速查询：在实际分析场景中，我们经常遇到分析百亿级大表的情况。尽管 StarRocks 性能优异，但数据量过大对查询速度还是有影响，此时在用户经常聚合的维度加上物化视图，在不改变查询语句的情况下查询速度能提升 10 倍以上。StarRocks 智能化的物化视图可以让请求自动匹配视图，无需手动查询视图。
3）CBO：CBO 优化器(Cost-based Optimizer ) 采用 Cascades 框架，使用多种统计信息来完善成本估算，同时补充逻辑转换（Transformation Rule）和物理实现（Implementation Rule）规则，能够在数万级别执行计划的搜索空间中，选择成本最低的最优执行计划。
4）自适应低基数优化：StarRocks 可以自适应地根据数据分布，对低基数的字符串类型的列构建一张全局字典，用 Int 类型做存储和查询，使得内存开销更小，有利于 SIMD 指令执行，加快了查询速度。ClickHouse 也有低基数优化，只是在建表时候需要声明，使用起来会麻烦一些。
极速的多表关联
在实时数据分析场景中只满足单表极速查询是不够的。为了加速查询速度，业内习惯于把多张表打成一张大宽表，大宽表虽速度快，但是带来的问题是极其不灵活，实时数据加工层是用 Flink 将多表 Join 成一张表写入大宽表。
当业务方想修改或增加分析维度时，往往数据开发周期过长，数据加工完成后发现已经错过了分析最佳时机。因此就需要更灵活的数据模型，把大宽表模式退归回星型模型或者雪花模型是比较理想的方法。
在此场景下，查询引擎对多表数据关联查询的性能成了关键，以往 ClickHouse 以大宽表为主，多表联查情况下无法保证查询相应时间，甚至有很大几率出现 OOM。StarRocks 很好解决了这个问题，大表 Join 性能提升 3-5 倍以上，成为星型模型分析利器。CBO 是多表关联极致性能关键，同时 StarRocks 支持 Broadcost Join、Shuffle Join、Bucket shuffle Join、Colocated Join、Replicated Join 等多种 Join 方式，CBO 可以智能地选择 Join 顺序和 Join 方式。