SQL Server 2022 不支持存储层聚合下推，真正有效的“下推”是通过 datetime2 列+B-tree 索引+time_bucket+严格 WHERE 时间范围过滤协同实现最小化数据扫描。

SQL Server 2022 本身不支持传统意义上的“聚合下推”（如 StarRocks 或 Doris 那种在存储层就完成局部 GROUP BY 的能力），所谓“下推”实际是指让聚合操作尽可能靠近数据源执行，避免中间结果膨胀。真正能起效的，是让 WHERE 过滤、time_bucket 分组、索引查找三者协同，把扫描范围压到最小——否则 GROUP BY 再快，也得先扫几百万行。

time_bucket 必须配合 datetime2 + B-tree 索引才有效

SQL Server 2022 的 time_bucket 函数（需 CU14+）只是语法糖，它本身不加速。加速的前提是：时间列必须是 datetime2 类型，且该列上建有 B-tree 索引（最好是包含索引）。否则优化器无法跳过无关数据块。

• 正确写法：CREATE INDEX IX_sensor_ts ON sensor_data(ts) INCLUDE (value, device_id)
• 错误写法：WHERE DATEPART(hour, ts) = 14 —— 函数包裹导致索引失效
• 更糟写法：SELECT time_bucket('5 minutes', CAST(ts AS VARCHAR)) —— 强制转换直接废掉所有下推可能

WHERE 时间范围过滤不能省，也不能写错

即使建了索引，没有显式 WHERE，SQL Server 也不会自动推导业务时间窗口。全表扫描仍会发生，GROUP BY time_bucket 只是在扫完之后才分组。

• 必须写：WHERE ts >= '2026-10-10' AND ts
• 避免写：WHERE ts BETWEEN '2026-10-10' AND '2026-10-11' —— BETWEEN 包含右边界，易因毫秒精度漏数据
• 绝对不要写：WHERE CONVERT(DATE, ts) = '2026-10-10' —— 转换函数禁用索引查找

列存储索引要进 Batch Mode，否则聚合几乎不加速

哪怕建了聚集列存储索引，如果执行计划里是 Row Mode，聚合性能和行存储差别不大。关键看是否触发批处理模式。

• 检查点：执行计划 XML 中搜索 BatchMode="1"；或用 sys.dm_exec_query_plan 提取后查 RelOp 节点
• 常见阻断项：数据库兼容级别低于 130；WHERE 用了 UPPER(col) = 'X'；连接字段类型不一致（如 INT vs BIGINT）
• 补救动作：ALTER DATABASE [db] SET COMPATIBILITY_LEVEL = 150（SQL Server 2022 对应 150）

非聚集索引 + 列存储组合会拖慢聚合

SQL Server 允许在聚集列存储表上再建 B-tree 非聚集索引，这对点查有用，但对聚合是负优化——优化器可能误选该索引路径，导致回表 + 逐行扫描，彻底绕开列存储的批处理能力。

• 验证方式：执行计划里看到 Index Seek 或 Key Lookup 而不是 Columnstore Index Scan
• 临时解法：查询时加 OPTION (TABLE HINT (YourTable, IGNORE_NONCLUSTERED_COLUMNSTORE_INDEX))
• 长期建议：除非高频点查需求明确，否则别在纯分析表上建非聚集索引

真正难的是数据物理分布与查询模式的匹配——比如按时间插入但总按设备 ID 聚合，行组内值高度混杂，谓词下推和行组消除就都失效了。这时候再调参数、建索引，效果也有限。得回到数据加载逻辑本身去调整顺序或预排序。