Rails中是否应采用模型归档方案处理历史价格数据？

现有归档方案的核心问题 #

• 跨模型合并排序需在Ruby内存中处理，数据量大时性能存在隐患（即便使用频率低）
• 订单等关联模型需新增price_archive_id字段，破坏原有关联结构，还会导致多表查询（如你提到的三次查询），增加代码复杂度

更优替代方案 #

方案1：单表+针对性索引优化 #

既然多数场景仅需查询非旧数据，直接给prices表做索引优化即可：

1. 给old字段添加单独索引：add_index :prices, :old
2. 给常用查询场景添加复合索引，比如产品价格查询：add_index :prices, [:product_id, :old, :time]
3. 查询时通过条件过滤，无需拆分模型：

   # 获取某产品的当前价格（多数场景）
   product.prices.where(old: false)
   # 获取某产品所有价格（含归档）
   product.prices.order(:time)
   # 订单关联查询（一次拉取所需数据）
   Order.where(your_conditions).includes(:part => { :prices => -> { where(old: false) } }, :price)
   

这种方案完全保留原有模型结构，无需修改关联逻辑，查询性能通过索引保障，维护成本极低。

方案2：数据库表分区（长期扩容方案） #

如果未来prices表数据量还会持续爆炸式增长，可采用数据库原生的表分区功能（比如PostgreSQL的范围分区）：

1. 按time字段将prices表分为「当前分区」和「归档分区」
2. 分区对应用层模型完全透明，依然使用Price模型操作
3. 查询时数据库会自动命中对应分区，性能接近拆分表，但无需修改关联逻辑
4. 合并排序直接通过SQL的ORDER BY time完成，数据库层面优化效率远高于Ruby内存排序

方案对比与结论 #

• 若当前250万数据量通过索引优化后能满足性能需求，优先保留old字段+索引优化，这是成本最低、复杂度最低的方案
• 若未来数据量增长到单表索引无法承载，选择数据库表分区，而非拆分模型成Price和PriceArchive——后者带来的关联复杂度和查询性能损耗，远大于拆分表带来的收益
• 你提到的拆分模型归档方案，仅适合完全隔离历史数据、几乎不需要跨模型查询的场景，显然不符合你的核心查询需求

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