SQL Server 不支持位图索引，所有版本均无法创建；列存储索引的位图编码是内部自动机制，不可显式控制；压缩仅减少I/O，不加速聚合逻辑，性能取决于I/O与CPU瓶颈平衡。
位图索引在 SQL Server 中不可用，压缩技术也不能直接加速聚合计算——它只减少 I/O，不改变执行计划逻辑。
SQL Server 不支持位图索引
SQL Server 的所有版本（包括 2022、Azure SQL）均未实现位图索引。该结构常见于 Oracle、PostgreSQL（通过 BITMAP 扩展）或列存引擎（如 ClickHouse），但 SQL Server 的查询优化器不识别位图扫描路径。试图在 SQL Server 中创建 CREATE BITMAP INDEX 会直接报错 Incorrect syntax near 'BITMAP'。
常见误判来源：有人把「列存储索引」的内部位图编码机制误解为“可显式创建的位图索引”。实际上，列存储索引的位图是自动启用的压缩子阶段，用户无法控制或单独利用它做谓词下推。
- Oracle 用户迁移到 SQL Server 时容易踩这个坑
- 执行计划里看到
Columnstore Index Scan并不等于你在用“位图索引” - 如果真需要位图语义（如低基数列上的快速
AND/OR合并），得靠应用层预计算或使用GROUP BY+COUNT(*)配合行压缩间接缓解
行压缩 / 页压缩对聚合性能的真实影响
开启 DATA_COMPRESSION = ROW 或 PAGE 后，聚合速度可能变快，也可能变慢——关键看瓶颈在哪：
- 若原始表 I/O 是瓶颈（比如磁盘慢、内存不足、大表全扫），压缩后页数减少 → 缓冲区命中率上升 →
SUM/COUNT等聚合实际更快 - 若 CPU 已饱和（尤其高并发小聚合），解压开销会抵消 I/O 节省，
AVG或带CONVERT的聚合甚至更慢 - 压缩对
GROUP BY的加速有限：分组键本身不压缩，且哈希/排序阶段仍需解压全部参与列 - 验证方法：对比
SET STATISTICS IO ON和SET STATISTICS TIME ON下的logical reads与CPU time变化
真正能加速大量重复值聚合的实操手段
与其依赖不存在的位图索引或不确定的压缩收益，不如直接干预数据组织和查询写法：
- 对低基数列（如
status TINYINT、region CHAR(2)）建NONCLUSTERED索引，并包含常用聚合字段：CREATE INDEX ix_status_on_orders ON orders(status) INCLUDE (amount, order_date) - 用
APPROX_COUNT_DISTINCT()替代COUNT(DISTINCT ...)（误差率 - 分区表按高频分组维度切分（如按
year_month分区），让GROUP BY year_month, status自动剪枝 - 避免在
GROUP BY列上用函数：GROUP BY YEAR(order_date)会禁用索引；改用已计算好的order_year列并建索引 - 确认统计信息是最新的：
UPDATE STATISTICS比默认采样更能帮优化器选对哈希匹配 vs 排序聚合
压缩和索引都是辅助手段，真正决定聚合快慢的是数据物理布局是否匹配查询模式。低基数列上盲目开压缩，反而可能因解压争用拖慢整体吞吐——先看执行计划里的 Actual Number of Rows 和 Number of Executions，再动手。
