一个商品表需要销量这个字段吗？
根据表设计的范式 销量可以由订单记录得出（或者建一个商品每日效果表，记录每天的效率），但是这样在实际中却遇到了这样的问题？
怎么查询时怎么根据商品的销量排序呢，还有按点赞数排序呢，收藏数呢？想淘宝这样的怎么做呢？
一个商品表需要销量这个字段吗？
根据表设计的范式 销量可以由订单记录得出（或者建一个商品每日效果表，记录每天的效率），但是这样在实际中却遇到了这样的问题？
怎么查询时怎么根据商品的销量排序呢，还有按点赞数排序呢，收藏数呢？想淘宝这样的怎么做呢？
销量是必须的，但是这一列可以不是实时的，你应该记上统计出这个数据的时候的时间。
我的建议是，你先给订单时间加index，然后每过一小时（这个时间看你的售货速度）统计一下cache下当时的销量，然后把销量和时间这两个列存下来。你在前端显示真实的销量的时候，就可以把cache的数据，加上cache之后发生的订单的总和相加。这样你过一段时间就incrementally地做一下，问题就解决了。
订单时间加index的意思就是说，你知道你目前的cache是到譬如说半个小时前，那你这样就很容易query出半个小时内发生的订单，每一次处理的数据都会非常少。因此这个系统的负担不会随着你订单的增加而变慢，你也不需要因为每一次订单就频繁的更改“销量”这个列而产生性能问题。
如果一秒钟就有几个人挤进来，那可能会总是有一点误差，不过稍微做点变通就解决了。
对于如何给销量排序，我觉得需要在缓存这一层来解决，不需要在数据库维护这个index。如果按照这种方法维护销量的话，虽然直接按照这个列排序是不正确的，但是他“基本正确”。对于这样的属性的数据有特殊的排序方法。其中的一种方法是，你做一个qsort的变形，但是用户看到哪里你才排序到哪里。通常你在前端让用户按照销量排序的话，他只会看最前面的或者最后面的。平摊到每一次查阅，复杂度基本是log(n)的。
这种方法基本上可以用到你的数据规模明显比淘宝少的时候。你真有了淘宝那么大的数据，那所有的事情都得改成分布式的。最后要么上spark，要么上sqlazure，要么上scope，做起来就差很远了。
表的设计应该按照实际情况来，如果这个字段用得频繁，考虑到查询效率可以增加。
在你有排序的场景下，销量字段是必须的，并且由于是经常更新的字段，很有可能会按实际情况拆分到子表里，举个例子，goods存储商品信息，goods_counter一对一goods表，并存储各种统计信息，包括不限于销量，查看数，收藏数，点赞数，并根据需要建立索引
很多实际的一定规模（用户数或者数据量）的系统，未必还会使用MySQL做排序，会把数据放入搜索引擎，比如elasticsearch, solr, sphinx等等，然后利用搜索引擎做排序
都按销量排序了，那就加上呗。
