Azure Table Storage数据过期设计：避免热键与全表扫描

针对你的单表设计需求，这里给几个实用的优化思路，解决热键和过期清理的问题：

• 时间分片分散热键
  不要用单一的expires作为分区键，而是按时间维度拆分，比如用expires:{yyyyMMddHH}（按小时分片）或者expires:{yyyyMMdd}（按天分片）作为过期记录的PartitionKey。每条Widget的过期记录RowKey可以设为{过期时间戳}:{WidgetID}，这样所有同小时到期的记录会落在同一个分区里。
  清理的时候，不用每次网站请求都触发，而是用Azure Functions定时任务（比如每小时跑一次），只扫描当前时间之前的分区（比如现在是10点，就处理expires:2024052009及更早的分区），既分散了热键，也把清理逻辑从请求链路中剥离，不影响用户体验。

• 复用Widget分区的过期标记
  在Widget的主记录里直接存储过期时间戳，然后定期（比如每天）做一次范围扫描：查询所有PartitionKey以widget:开头，且ExpiresAt字段小于当前时间的记录。不过这种方式需要注意，全表范围扫描在数据量小的时候没问题，但数据量大了会影响性能，适合你当前低流量的场景，但长期来看不如分片方案。

• 接受当前设计（低流量场景）
  你目前流量极低，单一expires分区的热键问题其实不会造成实际影响——Azure Table Storage单个分区的吞吐量足以应付小流量请求。这种简单的设计在小型应用里很普遍，没必要为了未来可能的流量提前过度优化，等流量增长后再切换到分片方案即可。

另外要注意，不管用哪种方案，删除Widget的时候一定要同步删除对应的过期索引记录，避免残留无效数据；同时，清理过期记录时，要先根据过期索引找到对应的Widget主记录和关联数据，再批量删除（Azure Table Storage支持批量操作，一次最多100条），提升清理效率。

内容的提问来源于stack exchange，提问作者Stephen Jennings