Question

我每周运行以下查询，但它现在需要22小时才能运行！报告的目的是在广告展示位置和日期汇总展示和转化数据，因此我查询的主要表格没有主键，因为可能有多个具有相同日期/展示位置的活动。

主数据集有大约400K记录，因此运行此报告的时间不应超过几分钟。

表格描述如下：

tbl_ads （400,000条记录）

day_est     DATE (index)
conv_day_est    DATE (index)
placement_id    INT (index)
adunit_id   INT (index)
cost_type   VARCHAR(20)
cost_value  DECIMAL(10,2)
adserving_cost  DECIMAL(10,2)
conversion1 INT
estimated_spend DECIMAL(10,2)
clicks      INT
impressions INT
publisher_clicks    INT
publisher_impressions   INT
publisher_spend DECIMAL (10,2)
source VARCHAR(30)

map_external_id （75,000条记录）

placement_id    INT
adunit_id   INT
external_id VARCHAR (50)
primary key(placement_id,adunit_id,external_id)

SQL查询

SELECT A.day_est,A.placement_id,A.placement_name,A.adunit_id,A.adunit_name,A.imp,A.clk, C.ads_cost, C.ads_spend, B.conversion1, B.conversion2,B.ID_Matched, C.pub_imps, C.pub_clicks, C.pub_spend, COALESCE(A.cost_type,B.cost_type) as cost_type, COALESCE(A.cost_value,B.cost_value) as cost_value, D.external_id
FROM (SELECT day_est, placement_id,adunit_id,placement_name,adunit_name,cost_type,cost_value,
    SUM(impressions) as imp, SUM(clicks) as clk
    FROM tbl_ads
    WHERE source='delivery'
    GROUP BY 1,2,3 ) as A LEFT JOIN
(
    SELECT conv_day_est, placement_id,adunit_id, cost_type,cost_value, SUM(conversion1) as conversion1,
    SUM(conversion2) as conversion2,SUM(id_match) as ID_Matched
    FROM tbl_ads
    WHERE source='attribution'
    GROUP BY 1,2,3
) as B on A.day_est=B.conv_day_est AND A.placement_id=B.placement_id AND A.adunit_id=B.adunit_id
LEFT JOIN
(
    SELECT day_est,placement_id,adunit_id,SUM(adserving_cost) as ads_cost, SUM(estimated_spend) as ads_spend,sum(publisher_clicks) as pub_clicks,sum(publisher_impressions) as pub_imps,sum(publisher_spend) as pub_spend
    FROM tbl_ads
    GROUP BY 1,2,3 ) as C on A.day_est=C.day_est AND A.placement_id=C.placement_id AND A.adunit_id=C.adunit_id
LEFT JOIN
(
    SELECT placement_id,adunit_id,external_id
    FROM map_external_id
) as D on A.placement_id=D.placement_id AND A.adunit_id=D.adunit_id
INTO OUTFILE '/tmp/weekly_report.csv';

EXPLAIN的结果：

+----+-------------+--------------------+-------+---------------+---------+---------+------+--------+----------------+
| id | select_type | table              | type  | possible_keys | key     | key_len | ref  | rows   | Extra          |
+----+-------------+--------------------+-------+---------------+---------+---------+------+--------+----------------+
|  1 | PRIMARY     | <derived2>         | ALL   | NULL          | NULL    | NULL    | NULL | 136518 |                |
|  1 | PRIMARY     | <derived3>         | ALL   | NULL          | NULL    | NULL    | NULL |   5180 |                |
|  1 | PRIMARY     | <derived4>         | ALL   | NULL          | NULL    | NULL    | NULL | 198190 |                |
|  1 | PRIMARY     | <derived5>         | ALL   | NULL          | NULL    | NULL    | NULL |  23766 |                |
|  5 | DERIVED     | map_external_id    | index | NULL          | PRIMARY | 55      | NULL |  20797 | Using index    |
|  4 | DERIVED     | tbl_ads            | index | NULL          | PIndex  | 13      | NULL | 318400 |                |
|  3 | DERIVED     | tbl_ads            | ALL   | NULL          | NULL    | NULL    | NULL | 318400 | Using filesort |
|  2 | DERIVED     | tbl_ads            | index | NULL          | PIndex  | 13      | NULL | 318400 | Using where    |
+----+-------------+--------------------+-------+---------------+---------+---------+------+--------+----------------+

Answer 1

更多的是一个推测性答案，但我认为22小时太不现实了。

首先要做的事情......你不需要最后一个子查询，只需要状态

LEFT JOIN map_external_id as D on A.placement_id=D.placement_id AND A.adunit_id=D.adunit_id

其次，在第一个和第二个子查询中，WHERE语句中包含字段source，并且此字段未在表格方案中列出。显然它可能是枚举或字符串类型，它有索引吗？我有一个大约1'000'000个条目的表，其中一个缺失的索引导致一个简单查询的处理时间为30秒（不能相信那个将查询放入登录过程的人）。

中间不相关的问题，最终的结果集大小是什么？

第三，我的假设是，通过运行聚合子查询，mysql实际上创建了没有任何索引的临时表 - 这很糟糕。您是否查看过单个子查询的结果集？典型的套装尺寸是多少？从您的陈述和我对典型数据的猜测，我会假设聚合实际上只是略微减少了设置大小（除了WHERE语句）。所以让我按子查询的顺序猜测：200'000,100'000,200'000

每个子查询然后在三个可能没有索引的字段上与下一个子查询连接。第一次加入的最坏情况是：200'000 * 100'000 = 20'000'000'000比较。从我的30秒开始查询1'000'000记录经验，使其成为20'000 * 30 = 600'000秒= + - 166小时。显然这太多了，也许有一个数字缺失，可能是20秒而不是30，结果集可能会有所不同，最坏的情况不是普通情况 - 但是你得到了图像。

我的解决方案方法是尝试创建替换聚合子查询的其他表。从您的查询来看，您可以每天更新它，因为我猜您只是在展示次数上插入行，因此您可以逐步添加聚合数据。然后，将您的大型查询转换为

的两个步骤

更新汇总表
做最后的转储。

聚合表显然应该有意义地编入索引。我认为应该将最终查询降低到几秒钟。

Answer 2

感谢您的所有建议。我最终拆分子查询并为每个创建临时表（使用PK），然后在最后将临时表连接在一起，现在需要大约10分钟才能运行。

为什么我的SQL查询这么慢？

tbl_ads （400,000条记录）

map_external_id （75,000条记录）

2 个答案: