结论是sql server 2014中大规模聚合必须用列存储索引+批模式执行，因行模式为单线程逐行处理，百万级以上即遇cpu/i/o瓶颈，且临时表会阻断批模式；列存储索引需建在只读事实表上并覆盖查询字段，避免函数导致失效。
直接说结论：在 SQL Server 2014 中，大规模聚合计算不能靠“堆临时表 + 分步 GROUP BY”硬扛，必须用列存储索引 + 批模式执行（Batch Mode）来撬动硬件并行能力——这是唯一能突破传统行模式瓶颈的路径。
为什么传统写法在百万级以上聚合里必然变慢
SQL Server 2014 的行存储引擎对聚合操作本质是单线程逐行扫描 + 哈希/排序构建，哪怕加了索引，面对千万级事实表的 SUM/COUNT/DISTINCT，CPU 和 I/O 都会卡在“等数据进来”的阶段。更麻烦的是，一旦你在存储过程中用了 #temp 或 @table_var 存中间聚合结果，就彻底断送了批模式机会——因为批模式只认物理列存储表或带列存储索引的视图。
常见错误现象包括：
- 执行计划里全是
Hash Match (Aggregate)和Sort，没有Columnstore Index Scan - 逻辑读远高于预期，
sys.dm_exec_query_stats显示total_logical_reads动辄上千万 - 同一语句，参数换一个范围，耗时从 800ms 跳到 12s——这是行模式下基数预估崩盘的典型信号
必须开启列存储索引 + 批模式执行
SQL Server 2014 支持非聚集列存储索引（Nonclustered Columnstore Index），它不替代主键或聚集索引，而是作为“聚合加速器”附加在事实表上。关键点不是“建了就能快”，而是要让查询真正命中它并触发批模式。
实操建议：
- 目标表必须是
SELECT主导、极少UPDATE/DELETE的事实表（如销售流水、日志明细）；频繁更新会触发索引重建阻塞 - 建索引时明确包含所有聚合字段和 WHERE 条件字段，例如：
CREATE NONCLUSTERED COLUMNSTORE INDEX IX_Sales_ColStore ON Sales (sale_date, store_id, amount, product_id) - 存储过程里避免对列存储字段做函数包装，比如
WHERE YEAR(sale_date) = 2025会跳过列存储；改用WHERE sale_date >= '2025-01-01' AND sale_date - 确认执行计划中出现
Batch Mode on Rowstore（2014 不支持纯行存批模式，但列存储索引启用后，关联小表时可部分受益）或Columnstore Index Scan节点
临时表与表变量在聚合链路中的取舍陷阱
很多人想“先用 #temp 把数据筛一遍再聚合”，这在列存储场景下是倒退。SQL Server 2014 对临时表完全不生成列存储统计信息，后续 JOIN 或 GROUP BY 全靠瞎猜，极易选错执行计划。
正确做法是把过滤和聚合尽量压进单条语句，绕过中间物化：
- 用
CTE替代SELECT INTO #t，尤其是当 CTE 只被引用一次时；但注意：CTE 不是缓存，别在循环里反复定义 - 表变量
@result只适合 ≤ 100 行的聚合结果传递（如返回 top 10 门店），绝不用来存几十万行的中间聚合集 - 如果真需要多步聚合（比如先按天汇总，再按月合并），优先考虑用窗口函数下推：
SUM(amount) OVER (PARTITION BY DATEADD(mm, DATEDIFF(mm, 0, sale_date), 0))，而不是建两个临时表
存储过程编译与参数嗅探必须手动干预
列存储索引虽快，但一旦执行计划因参数嗅探失准而退回到行模式扫描，性能直接归零。SQL Server 2014 默认不会为列存储查询自动重编译，所以首次调用的参数值决定后续所有行为。
实操建议：
- 对高频聚合过程，在关键参数上加
OPTIMIZE FOR (@date_from = '2025-01-01')，选一个有代表性的中等数据量日期，而非空值或极端边界值 - 避免在过程里写
IF @mode = 'daily' BEGIN ... END ELSE BEGIN ... END这种分支——不同分支可能走完全不同执行路径，强制拆成两个独立存储过程，各自缓存计划 - 检查
sys.dm_exec_procedure_stats中的plan_handle是否稳定；若plan_generation_num > 1，说明计划被反复丢弃重建，大概率是统计信息过期或 SET 选项不一致（比如一个地方设了SET ARITHABORT ON，另一个没设）
最易被忽略的一点：列存储索引本身不自动更新统计信息。哪怕你每天跑 UPDATE STATISTICS，也得显式加上 WITH FULLSCAN 或至少 WITH SAMPLE 50 PERCENT，否则优化器仍按老数据估算，批模式可能根本不会被选中。
