卖家可以设置一类商品在价格高于 x 元时每分钟自动降价 y 元，请问如何设计数据库效率最高？

商铺价格自动降价字段或者降价规则，用户访问的时候判断当前价格高于 X 元，高于 X 元跑降价字段或者降价规则

保存开始降价的 timestamp，当前价格计算得出行不？

@MeteorCat #1
@learningman #2 感谢回复，想到过这种方案，但这样如何实现搜索结果按价格排序呢？

后台跑一个进程一直不停的排序吧。应该没什么特别好的算法，因为降价的开始 /结束时间都不一致。

目标：商品类别。
逻辑：高于 X 元每分钟自动减少 Y 元。
不确定因素：
商品价格扣减 Y 元后是否允许高于 X 元？
每分钟自动降价是否有个价格 /时间阈值？

多一个条件和少一个条件做法都不一样，建议先确定好需求，再想方法。

显示价格是计算价格，数据库效率最高
至于排序，如果商品数量不是超级多，比如只有几百条几千条，维持一个实时价格榜单，在需要排序的时候调用就行。

具体电商业务理论上每次编辑商品信息都得创建新的商品快照，编辑价格也一样。所以创建假超管账户，然后走人工编辑创建快照的逻辑吧。

显然应该用 redis 作排序啊（笑

@markgor “每分钟”显然蕴含了你可以指望大部分情况下扣减 Y 元后是高于 X 元的。
也一定程度上暗示了终止条件是价格不高于 X 元为止。
但不确定因素还有：
如果输入错误，Y>X 是否会导致价格为负？（因为可能越过“用户输入校验”）
是否可能导致长时间大量行更新？表的大小是多少？数据库撑得住吗？

除此以外，这种逻辑简直是跟商业技巧反着来的：每等分钟你都能获得更优惠的价格，那么几乎所有人都会等价格降低，而一旦等待，就会造成强制冷静反思自己是不是需要这个商品。为了抵抗强制冷静，必须设置商品数量有限，实质是带一口价的拍卖，请直接换成拍卖。

什么数据库？ postgres 写个 procedure 用 pg_cron 后台 run 就行了

ms sql server 也有同样的功能

@MintZX 你这方法迁移性太差，不适合大规模电商业务。

lz 这明显是动态字段嘛，保留原价格字段，然后额外增加一个状态字段最好。
这似乎跟分表没啥必然联系啊。如果是为了提升效率那就增加一个动态计价的服务通过商品表中的状态字段关联，把价格计算与最终成交订单数据分离，服务挂了可以降级为：价格不变原价交易。

redis 有序集合， 商品 id 为 key， 价格为 score.