嘿，针对你提到的7天SKU数据标签页展示需求，我来分享下实战思路——完全不需要给每一天单独创建索引，有更高效、易维护的方案可以选：

为什么不推荐每日建索引？ #

• 冗余与维护成本爆炸：7天就要建7个索引，后续如果要扩展到更长周期（比如30天），索引数量会直线上升。而且同一SKU重复出现在不同索引里，会造成大量数据冗余，存储空间浪费不说，每次更新数据还要同步多个索引，运维成本极高。
• 扩展性极差：哪天业务需求改成展示14天数据？难道要再新建7个索引？这种方案完全不具备弹性。

更高效的实现方案：单索引+日期字段优化 #

核心思路 #

在你的SKU数据结构中新增一个record_date字段（比如"record_date": "2028-05-20"），用来标记这条数据对应的日期。然后基于这个字段做以下优化：

1. 创建复合索引
   建立(record_date, skuId, storeId)的复合索引。这样做的好处是：

   • 快速筛选指定日期的所有数据（对应标签页切换场景）
   • 高效定位某一SKU在特定日期的记录（如果需要做SKU的跨日对比）

2. 可选：按日期分区（针对大数据量场景）
   如果每日的SKU数据量极大（比如百万级以上），可以给索引按record_date做按天分区。查询时直接命中对应分区，能进一步提升查询性能，而且清理过期数据时直接删除分区即可，非常高效。

实际使用场景适配 #

• 标签页切换查询：用户切换到某一天的标签时，只需在查询条件中加入record_date = '目标日期'，配合复合索引，查询速度和单独建索引几乎无差别，但维护成本低太多。
• 数据写入：每天新增当日数据时，直接往同一个索引写入带record_date的记录即可，无需额外操作。
• 过期数据清理：如果只需要保留7天数据，直接删除record_date早于7天前的记录，或者用索引生命周期管理工具自动清理过期数据，省心又省力。

两种方案对比 #

内容的提问来源于stack exchange，提问作者Vijay Kumar Rajput