星型模型通过主从结构简化连接逻辑，为查询优化创造条件；其索引策略需聚焦事实表外键与高频过滤列、维度表主键，辅以统计更新和物化汇总等措施提升性能。
星型模型本身不直接提供索引，但它是构建高效查询的基础结构；真正起加速作用的是在事实表和维度表上合理设计的物理索引策略。
星型模型如何为查询优化创造条件
星型模型通过清晰的主从关系（一个事实表 + 多个维度表）简化了连接逻辑，减少了歧义连接和冗余路径。查询通常围绕“事实表为中心、关联少数维度”展开，这使得优化器更容易生成稳定、可预测的执行计划。
关键点包括：
- 维度表体积小、主键稳定（如 date_key、product_id），适合建聚集索引或唯一索引
- 事实表宽而深，高基数连接列（如 date_key、customer_key）是索引重点，而非业务字段
- 避免在事实表上对度量列（如 sales_amount）单独建索引——除非有高频范围扫描且过滤性强
事实表索引策略：聚焦连接与过滤列
事实表的查询性能瓶颈多出现在 JOIN 和 WHERE 条件上。应优先为以下列建立索引：
- 外键列：每个维度关联字段（如 time_key、store_key）建议建非聚集索引；若常组合过滤（如 “2023年北京门店”），可建复合索引（time_key, store_key）
- 高频时间分区列：即使使用表分区，仍建议在 date_key 或 order_date 上建索引——分区剪枝依赖统计信息，索引可加速定位具体分区内的数据
- 常用筛选+分组列组合：例如查询“各产品类别的季度销售额”，则 product_category_id + quarter_key 的覆盖索引能避免回表
维度表索引要点：主键即核心，谨慎扩展
维度表通常较小（几千至百万行），但主键被频繁用于哈希匹配或查找。优化重心明确：
- 主键自动索引必须保留：这是星型模型 JOIN 正确性和性能的基石
- 避免为低选择性字段（如 gender、is_active）单独建索引——全表扫描可能更快
- 若存在“描述类模糊查询”（如 product_name LIKE '%wireless%'），可考虑添加全文索引或使用专用搜索服务，而非普通 B-Tree 索引
其他实用建议
除索引外，配合星型模型的查询习惯，还可落地以下措施：
- 统计信息定期更新：尤其在大批量加载后运行 UPDATE STATISTICS，防止优化器误判行数导致嵌套循环变哈希连接
- 物化常用汇总：对高频聚合（如日销售汇总、区域月报）预计算并存入汇总表，比实时 GROUP BY + JOIN 更快
- 避免 SELECT *：只取所需维度属性和度量，减少网络传输与内存压力，也利于索引覆盖
