2GB以上可加快单个表上的SQL查询

Question

我正在对MYSQL数据库中非常大的表中的广告收入进行查询。 它包含许多维度，例如设备类别，日期，广告客户，垂直，creative_size，位置等，以及一些指标，例如投放的展示次数，点击次数和收入。

该表用于显示广告效果，因此通常按一两个维度进行分组并按维度进行过滤。

我将所有内容都放在一张表中，以避免连接并使其尽可能快，但是由于维数特别是。 广告客户，这个表很大，已经超过2.8Gb，并且还在增长。

我曾尝试建立索引和进行分区，但仍然很慢，因此我正在考虑通过将数据按较小的维度集进行分组来创建较小的版本，而忽略广告客户列，即

Select date, creative_size, device_class,ssp,billing_type, location,
       ad_impressions, clicks, revenue
  from ADS
 group by date,creative_size,device_class,ssp,billing_type,location

这将大大减少行数。

我试图将其用作视图，但是它不会永久存储，因此需要更长的时间。 如何创建这样的表并根据其他表保持最新状态？ 我需要编写脚本还是可以使用一些内置的MySQL功能？ 那是可行的方法吗？ 我当然愿意接受其他解决方案:)

Answer 1

您是正确的，MySQL的VIEW对象无助于查询性能。 用行业术语来说，它们不是“物化视图”。

您尚未向我们透露您使用的实际查询或大表的实际布局。 因此，具体建议实际上是不可能的。

您有一些可能的方法来提高查询性能。

1. 如您建议的那样，从明细表中生成一些汇总表。 如果您能够处理稍微陈旧的数据，则可以在一夜之间重新生成它们。

2. 如果您使用特定的查询，请研究创建复合覆盖索引以加速这些查询 。

查看您问题中的查询。 首先，我想它应该包含一些SUM项，就像这样。 我还将您提到的date更改为DATE(date)以仅获取日期，而不是摘要中的日期和时间。 （也许这已经在您的表中完成了。如果是这样，就不要再做一次。）

Select DATE(date), creative_size, device_class,ssp,billing_type, location,
       SUM(ad_impressions), SUM(clicks), SUM(revenue)
  from ADS
 group by DATE(date),creative_size,device_class,ssp,billing_type,location

其次，这个没有任何WHERE子句。 如果您确实添加了WHERE子句，则（几乎可以肯定）您需要不同的复合覆盖索引。 您可以在其他地方了解如何将覆盖索引与WHERE子句一起使用。

第三，可以通过特定的复合索引来加速该查询：复合索引在GROUP BY和SELECT子句中提到的所有列上。 GROUP BY子句中的列应在索引中排在第一位，通常与GROUP BY中的顺序相同。 您将创建这样的索引。

 CREATE INDEX summary_1 ON ADS 
              (date, creative_size, device_class,ssp,billing_type, location,
               ad_impressions, clicks, revenue);

这是有帮助的，因为MySQL的查询计划程序可以按顺序读取索引以满足您的查询，而不必遵循指向表的指针。

第四，你可以做

CREATE TABLE ad_summary AS
Select date, creative_size, device_class,ssp,billing_type, location,
       SUM(ad_impressions), SUM(clicks), SUM(revenue)
  from ADS
 group by date,creative_size,device_class,ssp,billing_type,location;

这是一个穷人的物化观点。 （如果您使用的是Oracle，则可以使用它们的实体化视图，我们将它们称为以前的富人的实体化视图 。-以前是因为Oracle如此昂贵。）

第五，您可以对汇总表进行日期限制（如果适用于您的应用程序）。 为此，可以在查询中添加类似的内容。

  WHERE date >= CURDATE() - INTERVAL 7 DAY

该特定的WHERE子句可以使用相同的复合覆盖索引，因为它对date进行范围扫描，并且该列在索引中位于第一位。

这是一些有关磨削非常大的桌子的一般观察，供您考虑。

• 像您这样的表上的许多单列索引通常会影响性能。 MySQL根本无法很好地利用单个查询的单个表中的多个索引。
• SELECT * 绝对对性能有害，特别是当您有很多列时。 而是，枚举所需的列。
• 除非您知道需要大型查询，否则请避免使用ORDER BY子句。
• http://use-the-index-luke.com/是使这些工具正常工作的很好参考。