向量化执行回退：不是所有算子都能吃满 SIMD

向量化执行回退：不是所有算子都能吃满 SIMD

一、向量化执行也有回退路径

向量化分析引擎通过列式数据、批处理和 SIMD 提高扫描与计算效率。但不是所有算子都能稳定向量化。复杂表达式、分支逻辑、字符串处理、低选择率过滤和类型转换，都可能触发回退或收益下降。

分析向量化性能时，不能只看引擎支持向量化。要看实际查询计划中哪些算子向量化，哪些退回标量路径，退回原因是什么。否则性能问题会被“向量化引擎很快”这句话掩盖。

二、执行链路要看算子级别

flowchart TD A[列式块] --> B[过滤算子] B --> C[表达式计算] C --> D[聚合] D --> E[输出] C --> F[标量回退]

向量化的优势来自批量处理。如果中间某个算子频繁回退，整个 pipeline 的吞吐会下降。尤其是字符串函数和复杂 UDF，常常成为瓶颈。

低选择率过滤也要注意。如果过滤条件很复杂，计算成本可能超过减少数据量的收益。优化器需要评估过滤位置和表达式成本。

三、Benchmark 要隔离算子

SELECT sum(revenue) FROM fact WHERE region = 'east' AND event_date >= '2026-01-01';

简单聚合可以验证扫描和基础过滤性能。复杂表达式测试则要单独设计，不要把 IO、解压、Join、聚合全部混在一起，否则无法定位瓶颈。

operator_benchmark: scan_mb_per_sec: 3200 filter_selectivity: 0.12 scalar_fallback_ratio: 0.18

回退比例是很有价值的指标。如果某类查询回退比例高，就要优化表达式实现、数据类型或 UDF 策略。

四、优化要考虑数据形状

SIMD 对连续、类型稳定、分支少的数据更友好。稀疏数据、可变长字符串、NULL 值很多的列，会让向量化收益下降。数据治理和执行引擎优化是连在一起的。

还要避免为了向量化牺牲语义。某些复杂类型或精度要求不能随便简化。性能优化必须建立在结果正确的前提上。

NULL 处理是常见回退来源。向量化执行需要在批量计算中维护 null bitmap，一些表达式在 NULL 和非 NULL 混合时会增加分支。若数据列 NULL 比例很高，实际收益可能低于纯净数据 Benchmark。

UDF 也是风险点。很多自定义函数按行处理，无法被引擎向量化。一个查询前半段跑得很快，后半段在 UDF 上退回标量路径，整体吞吐仍然上不去。治理时要统计 UDF 调用成本。

数据块大小也会影响性能。block 太小，函数调用和调度开销占比高；block 太大，缓存局部性和内存峰值可能变差。向量化执行不是简单把批次调到最大。

最后，优化报告要把“理论支持”和“实际命中”分开写。引擎支持某算子向量化，不代表当前查询真的走了向量化路径。

还要关注编码格式。字典编码、Run-Length Encoding、Delta 编码会影响向量化算子的实现方式。某些编码下计算可以直接在编码值上完成，某些则需要解码后再算。解码成本常常被 Benchmark 忽略。

Join 和聚合也有批处理边界。哈希表构建、分组键比较、聚合状态更新，都可能因为数据倾斜或状态过大导致缓存命中下降。向量化不是只发生在扫描层，整个 pipeline 都要看。

最后，真实优化要从 profile 出发。CPU 火焰图、硬件计数器和算子耗时统计，比单纯猜测更可靠。没有 profile，向量化调优很容易变成换参数试运气。

五、总结

向量化执行需要关注算子级回退、表达式复杂度、数据类型和过滤选择率。Benchmark 应隔离算子，并记录标量回退比例。

向量化不是魔法。数据形状和算子实现不合适时，SIMD 也吃不满。