按动态计算属性排序时如何高效实现分页

以下是生产环境验证过的可落地方案，按推荐优先级从高到低排列：

• 方案1：数据库层聚合计算排序字段，全逻辑下推数据库
  这是性能最优、改造成本最低的首选方案。首先需要修正建模逻辑：订单关联的商品子表必须存储下单时点的成交单价、购买数量、分摊优惠等金额快照，绝对不能实时关联商品主表的当前售价计算订单金额（否则不仅分页有问题，订单金额本身就会随商品调价出错，不符合电商业务的基本合规要求）。
  完成快照字段冗余后，直接通过SQL聚合计算每个订单的总成本，排序、分页逻辑完全在数据库层执行，示例SQL如下：

  SELECT 
    o.*,
    SUM(oi.deal_price * oi.buy_count - oi.share_discount) AS total_cost
  FROM order_info o
  LEFT JOIN order_item oi ON o.order_id = oi.order_id
  GROUP BY o.order_id
  -- 排序必须追加唯一主键作为兜底，避免金额相同时排序不稳定导致分页漏数/重复
  ORDER BY total_cost DESC, o.order_id DESC
  LIMIT #{pageSize} OFFSET #{offset}
  

  该方案和普通单字段分页性能基本一致，只要在关联字段、排序字段上建好索引，百万级数据量下查询延迟完全可以接受。

• 方案2：冗余持久化总成本字段，直接用字段排序分页
  如果总成本计算逻辑过于复杂（比如需要叠加跨服务的会员权益、实时营销活动抵扣、多级分销返点等规则，无法通过SQL聚合实现），直接在订单主表新增total_cost字段持久化存储计算结果即可。
  触发更新的时机可以选：订单创建时同步计算写入、订单发生改价/退款/优惠调整等金额变动操作时同步更新，再配合定时任务每日兜底校准近30天变动订单的金额，保证数据一致性。后续排序分页直接按该字段执行，和普通订单字段没有任何区别。

• 方案3：搜索引擎预计算承载排序分页
  如果你的接口本身就需要支持多维度复杂筛选（比如按订单状态、下单时间、商品类目、金额区间等组合查询排序），可以直接把订单数据同步到Elasticsearch等搜索引擎中，数据同步环节就提前计算好每个订单的总成本存入索引文档。分页、排序、筛选逻辑全部走搜索引擎完成，拿到分页结果对应的订单ID后，再回数据库查询完整的订单详情返回即可。该方案灵活度最高，适合中大型电商系统的复杂查询场景。

踩坑提醒：不要尝试在全量数据拉取到服务端内存后再做Skip/Take分页，订单量超过10万条后，接口延迟、数据库带宽占用、服务内存占用都会出现明显瓶颈，完全无法支撑生产流量。另外无论使用哪种方案，只要排序字段存在重复值，必须追加全局唯一的订单主键作为第二排序规则，否则存储引擎返回相同值的顺序是不稳定的，会直接导致分页结果错误。

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