一个商品表需要销量这个字段吗？

完全取决于你的数据量，如果你的系统数据量很小，销量更新和查询的次数不大，那么为了实现的简单，完全可以放一个销量字段，出售一笔订单就更新一次销量。好处是逻辑简单，维护容易。如果销量非常大，更新频率多，那么更好的做法应该是把销量放到cache里，挑战就是要设计cache更新的策略，以及如何保证cache和db之间的数据一致性。

销量是必须的，但是这一列可以不是实时的，你应该记上统计出这个数据的时候的时间。

我的建议是，你先给订单时间加index，然后每过一小时（这个时间看你的售货速度）统计一下cache下当时的销量，然后把销量和时间这两个列存下来。你在前端显示真实的销量的时候，就可以把cache的数据，加上cache之后发生的订单的总和相加。这样你过一段时间就incrementally地做一下，问题就解决了。

订单时间加index的意思就是说，你知道你目前的cache是到譬如说半个小时前，那你这样就很容易query出半个小时内发生的订单，每一次处理的数据都会非常少。因此这个系统的负担不会随着你订单的增加而变慢，你也不需要因为每一次订单就频繁的更改“销量”这个列而产生性能问题。

如果一秒钟就有几个人挤进来，那可能会总是有一点误差，不过稍微做点变通就解决了。

对于如何给销量排序，我觉得需要在缓存这一层来解决，不需要在数据库维护这个index。如果按照这种方法维护销量的话，虽然直接按照这个列排序是不正确的，但是他“基本正确”。对于这样的属性的数据有特殊的排序方法。其中的一种方法是，你做一个qsort的变形，但是用户看到哪里你才排序到哪里。通常你在前端让用户按照销量排序的话，他只会看最前面的或者最后面的。平摊到每一次查阅，复杂度基本是log(n)的。

这种方法基本上可以用到你的数据规模明显比淘宝少的时候。你真有了淘宝那么大的数据，那所有的事情都得改成分布式的。最后要么上spark，要么上sqlazure，要么上scope，做起来就差很远了。