列式执行引擎在分析型场景中性能突出，因其按列组织数据，显著减少I/O、提升压缩率、支持向量化计算、实现谓词下推与延迟物化，并天然适配OLAP聚合模型。
列式执行引擎在分析型场景中表现突出，核心在于它按列组织和处理数据，而非传统行式引擎那样按整行读取。这对聚合、过滤、扫描等典型分析操作带来显著性能提升。
减少I/O开销：只读所需列
分析查询通常只涉及少数几列（如SELECT sum(sales), avg(price) FROM orders WHERE region='CN'），列式引擎仅加载sales和price两列数据，跳过其余几十列（如user_id、address、notes等）。行式引擎则需读取整行，哪怕只用其中1个字段，也会带入大量无关数据，造成磁盘或内存带宽浪费。
- 实际场景中，列存表的I/O量常比行存低60%–90%
- 配合压缩（如字典编码、RLE），列内数据相似度高，压缩率更高，进一步降低存储与传输成本
向量化执行加速计算
列式引擎天然适合批量处理同类型数据。它把一整列数据以数组形式加载到CPU缓存，再用SIMD指令（如AVX）一次处理数百个值，大幅减少分支判断和函数调用开销。
- 例如COUNT、SUM、WHERE price > 100等操作，在向量化路径下吞吐量可提升3–10倍
- 现代列式引擎（如ClickHouse、Doris、StarRocks）默认启用向量化执行器，无需手动干预
高效谓词下推与延迟物化
列式引擎可在扫描阶段快速应用过滤条件（如WHERE status = 'paid'），利用列级索引（Zone Map、Bloom Filter）跳过不匹配的数据块；同时推迟构建完整行结构（即“物化”），直到真正需要输出结果时才组合各列对应行——避免为被过滤掉的行浪费内存和CPU。
- 对高选择性过滤（如WHERE user_id IN (…10个ID…)），能跳过99%以上数据块
- 结合稀疏索引，范围查询（如time BETWEEN '2024-01-01' AND '2024-01-31'）也能快速定位
天然适配OLAP聚合模型
星型/雪花模型中的事实表动辄数十亿行、上百列，但分析常聚焦于维度聚合（GROUP BY city, product_category）。列式引擎让GROUP BY操作可并行扫描多个列数组，哈希聚合直接作用于紧凑的列数据块，中间结果更小、缓存更友好。
- 相比行式引擎，相同硬件下QPS提升2–5倍，P99延迟下降明显
- 支持实时物化视图（如Rollup表、Aggregate Models），预聚合结果也按列存储，进一步加速高频统计
不复杂但容易忽略：列式优势不是绝对的，它在高并发点查、频繁更新、宽列小结果集等场景并不占优。选型时需紧扣“大批量扫描+有限列+强聚合”这一分析型典型模式。
