為什么我的SQL查詢這么慢？

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，結果集可能會有所不同，最壞的情況不是普通情況 - 但你得到了圖像。

我的解決方案方法是嘗試創建替換聚合子查詢的其他表。 從您的查詢來看，您可以每天更新它，因為我猜您只是在展示次數上插入行，因此您可以逐步添加聚合數據。 然后你將你的超級查詢轉換為兩個步驟

1. 更新聚合表
2. 做最后的轉儲。

顯然，聚合表應該被有意義地索引。 我認為應該將最終查詢降低到幾秒鍾。

Answer 2

謝謝你的所有建議。 我最終拆分子查詢並為每個創建臨時表（使用PK），然后在最后將臨時表連接在一起，現在需要大約10分鍾才能運行。