这种方法是增加MySQL性能的好主意还是坏主意？

Question

我正在构建一个电子商务CMS，在管理部分我想要显示所做出的订单总数，所述订单的总收入，并且还分别显示每个类别的总计。

我可以通过查询各种表格和计数总和做到这一点，但是这会是一个更好的办法：

相反，我想有一个表，看起来像这样（并且只有一个记录）的：

id | total_orders | total_earnings | toy_cat_sales | apparel_cat_sales | etc... 
-------------------------------------------------------------------------------- 
1 | 10   | 10034   | 4    | 6     | etc... 

现在每一个购买，则我能有这样的记录进行更新，例如，当一个新的玩具订单，我一定可以更新toy_cat_sales列，也是total_orders和total_earnings列以反映新的购买时间。

在实际查找过程中，这个查询一个表，只是显示它的值将obvisly比与可能的记录数万多个表进行统计和计算快得多。

但就是这种方法值得的整体？我知道只有一个管理员和许多客户。与管理员在后台查看这些统计数据相比，订单也会更多。因此，如果第二种方法得到实施，更新将比管理端的查找更多。

我不是MySQL的专家，所以你会在这里的专家做的，我只是与去。

Answer 1

你这种方法遇到的问题是，你拥有的每一个新产品进行一次新的列添加到该表。你真的不想那样做。

如果你的产品表中的每行都是一个产品，一个订单表和一个orders_products表，它具有fk的订单和产品以将每个产品从一个产品该订单的特定顺序。然后在需要时收拾一切。计算机执行该计算所需的时间与上述想法浪费维护的时间毫无关系，特别是一旦开始向该表添加新列并且其中有数百万行时，这需要一些时间。

Answer 2

这可能不是一个好主意。

虽然它会做出一些简单的查询/更快，这是每个插入额外的工作。更不用说保持更新的新编程要求。你似乎意识到，当你承认'订单会发生很多'时，这在你的最后一段中是不值得的'

这个单行表解决方案也不是很可扩展的。每个类别都需要自己的COLUMN，需要更改表格。

我觉得你最好的办法是写一个查询需要的时候找到这些统计数据。至多是一个观点。其中任何一个都可以包含与分类表的连接，从而使其对类别的添加（或删除）具有更大的可扩展性。

即使您决定保留此元数据是有价值的（最有可能不是这样），但有比这张表更好的方法。