組通過使查詢天文學更長

*作爲第一個注意事項，我只能讀取我的服務器。只是，僅供參考，因爲它似乎來了很多......組通過使查詢天文學更長

服務器：DB2（6.1），其中i（IBM）

我有一個查詢，我就在它有19mil行的表運行（我不設計它們，我只是查詢它們）。我一直限制我的返回數據爲10行（*），直到我得到這個查詢整理出來，以便返回時間有點合理。

的基本設計是，我需要得到的數據有關的按周基礎上，我們在一個星期賣的產品類別，使用列：WEEK_ID，和類別。這裏的示例代碼（有一些重要的位####出）。

SELECT WEEK_ID, CATEGORY 
FROM DWQ####.SLSCATW 
INNER JOIN DW####.CATEGORY 
ON DWQ####.SLSCATW.CATEGORY_NUMBER = DW####.CATEGORY.CATEGORY_NUMBER 
WHERE WEEK_ID 
BETWEEN 200952 AND 2--Format is year/week 
GROUP BY WEEK_ID, CATEGORY

如果我註釋掉最後一行，我可以在254毫秒拿回100行。如果我把這條線放回我的迴歸時間比我耐心等待的時間要長:-)。（最長我等了10分鐘。）

這個問題有兩個部分。第一個問題很簡單：這是正常的嗎？有50個類別（粗略）和140個星期（左右），我試圖壓縮。我意識到這是很多信息來冷凝19mil行，但我希望限制我的查詢10行返回將最小化時間？

而且，如果我不只是一個完整的n00b，這其實不應該需要幾分鐘的時間，究竟是什麼毛病我的SQL？

我谷歌搜索WHERE語句優化，似乎無法找到任何東西。所有的鏈接和解釋都是值得歡迎的。

道歉這樣的新手帖子...我們都必須從某個地方開始，對吧？

（*）使用SQLExplorer視窗，我的IDE，一個Eclipse實現松鼠的SQL。

來源

2012-12-12 Jay Carr

爲什麼'group by'？我看不到聚合..？ –

你是否真的在尋找'distinct'，有任何機會？ –

好問題。對於每個日期/類別組合，都有幾千個不同的條目（至少當你考慮表中的所有信息時）。但是對於我拉回來的數據，我並不關心那些不同的列，試圖摺疊行。我應該使用Select Distinct嗎？既然我不拉回不同的行？ –

我不確定當查詢中沒有聚合函數時服務器如何處理group by。基於在評論你的答案，我只是嘗試添加這些：

SELECT 
    ..., 
    SUM(SalesCost) as SalesCost, 
    SUM(SalesDollars) as SalesDollars 
FROM 
    ...

保留查詢的其餘部分是。

如果這樣不能解決問題，則可能缺少索引。我會嘗試找出是否有在WEEK_ID是唯一列或它是第一列的索引。您還可以檢查是否在已編制索引的同一個表上有另一個時間列（即TransactionDate或類似的東西）。如果是這樣，你可以在where條款中使用它。

如果沒有正確的索引，數據庫服務器被迫做一個完整的表掃描，這可能說明你的性能問題。 3900萬行的確需要花費一些不小的時間從磁盤讀取。

同時檢查WEEK_ID的數據類型爲int或類似的，只是爲了避免在查詢中不必要的鑄造。

要避免類別表上的表掃描，您需要確保Category_Number也是索引。（它可能已經是，因爲我認爲它是該表的關鍵。）上WEEK_ID

來源

2012-12-12 17:11:25

我添加了聚合，並能夠在26秒內拉下大約1,000,000條記錄。整個數據庫有36億條記錄（不是前面引用的1.9Mil）。所以，從理論上講，整個事情應該在15分鐘內運行（我現在正在測試我的理論）。它看起來還是很慢......或者這是正常的嗎？ –

我不會說「正常」 ......你'where'條款限制了需要處理的數據量，但只有工作，如果WEEK_ID被索引 - 否則它仍然需要全表掃描。內部連接是否必需？（我只問，因爲我不知道你從哪裏得到SalesCost/SalesDollars列。） –

還有一件事。你說你拉了一百萬行。我以爲你最多預計7000行（140周x 50類）。我錯過了什麼？ –

指數，類別（以及可能CATEGORY_NUMBER）是使它非常快的唯一途徑，所以你需要說服DBO介紹這些。

來源

2012-12-12 21:49:46 Morten

組通過使查詢天文學更長

回答

相關問題