事实表索引设计需聚焦查询特征建复合索引、谨慎设置聚集索引、对低基数维度用位图索引，并定期分析执行计划精简无效索引，以提升SQL报表性能。
事实表索引设计是星型模型下SQL报表性能提升的关键环节，核心在于支撑高频查询模式、避免全表扫描、加速聚合与过滤。不合理的索引不仅无效，还拖慢写入和占用存储。
聚焦查询特征建复合索引
星型模型中，报表查询通常按维度字段过滤（如 date_key、product_id、region_id），再对度量字段（如 sales_amount）做聚合。单列索引效果有限，应按“过滤+分组+排序”顺序构建复合索引。
- 高频时间范围查询？把 date_key 放在复合索引最左侧（例如
(date_key, product_id, region_id)） - 常按产品+地区汇总销售？索引可设为
(product_id, region_id, date_key)，兼顾等值过滤与范围扫描 - 含
ORDER BY sales_amount DESC LIMIT 10？将 sales_amount 加入索引末尾，支持索引覆盖排序（如(date_key, product_id, sales_amount)）
谨慎使用聚集索引（Clustered Index）
在支持聚集索引的数据库（如 SQL Server、MySQL InnoDB）中，事实表主键常默认作为聚集索引。若主键是代理键（如自增ID），物理存储会按ID顺序排列，但报表查询极少按ID过滤——这会导致大量随机I/O。
- 优先将聚集索引建在高选择性且高频过滤的列上，例如 date_key（尤其分区表中按日期分区时）
- 若使用日期分区，聚集索引与分区键一致（如
date_key）可显著提升分区裁剪效率 - 避免在宽事实表上用多列组合做聚集索引，会放大INSERT/UPDATE开销
利用位图索引加速低基数维度过滤
对取值有限、重复率高的维度字段（如 order_status（'pending','shipped','cancelled'）、is_promo（0/1）），B-Tree索引效率低，而位图索引在OLAP场景下压缩率高、AND/OR运算快。
- Oracle、Greenplum、Amazon Redshift 原生支持位图索引，适用于事实表中低基数维度列
- 注意：位图索引不适合高并发DML场景，仅推荐只读或批量加载后构建
- 可与B-Tree索引共存——例如用B-Tree加速
date_key范围查询，用位图加速is_promo = 1 AND order_status = 'shipped'
定期分析执行计划并精简索引
生产环境中，索引不是越多越好。未被使用的索引浪费空间、拖慢ETL，并可能干扰优化器选择最优路径。
- 启用数据库索引使用统计（如 PostgreSQL 的
pg_stat_all_indexes，SQL Server 的 DMVsys.dm_db_index_usage_stats） - 每季度检查
user_seeks = 0且last_user_seek为空或久远的索引，评估是否下线 - 对重复功能的索引合并：例如已有
(date_key, product_id)和(date_key, product_id, region_id)，前者通常可删除
索引设计不是一劳永逸，需随报表需求演进持续调优。从真实慢查SQL出发，结合执行计划反推缺失索引，比凭经验预建更可靠。
