时间序列统计场景下数据库多记录与多列方案的SELECT性能对比

结论 #

你描述的固定时间粒度聚合场景下，多列方案的SELECT性能明显优于多记录方案，但该优势存在适用边界，同时会带来部分功能灵活性的牺牲。

性能优势的核心原因 #

• 行扫描开销大幅降低：1年周期下多记录方案要扫描52.56万行，多列方案仅需扫描2.16万行，行扫描量差了24倍，做范围聚合时的磁盘IO、内存加载开销会低一个数量级。
• 聚合计算逻辑更简单：做日、月等长周期聚合时，多列方案仅需对每行的h_1到h_24字段求和后再做上层聚合，不需要像多记录方案一样先按天/小时做分组排序，省掉了分组带来的CPU开销。
• 存储占用更低：相同数据量下，多列方案的元数据（每条记录的行头、索引项）占用远少于多记录方案，缓存命中率也会更高。

注意事项与适用边界 #

这个性能优势只适配你当前固定统计粒度的场景，存在两个明显限制：

• 灵活性差：如果后续需要调整统计粒度（比如改为按15分钟聚合）、或者要查询任意时间片段的明细数据，多列方案需要改表结构，甚至要重构全部历史数据，远不如多记录方案灵活。
• 写入开销更高：每秒一次的写入/更新操作下，多记录方案仅需操作单条对应时间粒度的行，多列方案需要找到对应日期的行、再更新对应小时的字段，写操作复杂度更高，不过你当前的写入量级很低，这个差异可以忽略。

另外要提的是，你当前多记录方案性能差，大概率是没有做针对性优化导致的：给time字段加主键/索引、按时间做表分区，配合时序数据库的列存、预聚合优化，多记录方案的性能也能达到可用标准，同时保留更好的灵活性。

选型建议 #

如果业务长期不会变更统计粒度、也没有细粒度时间范围的查询需求，直接选多列方案即可。如果需求存在不确定性，优先优化现有多记录方案，性能无法满足再切换多列。

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