我的BI開發人員寫了一個查詢，花了14個小時來運行，我正試圖幫助他。 在高層次上，這是一個探索過去15年的財務交易并將其分解到每個季度的查詢。
我在這里分享我已經給他的答案，但我想知道你是否有任何建議，我們可以進一步探索和研究，以提高性能，答案如。"也許你可以看看快照......"
他的查詢包括：1.
他的詢問包括：
- 包括使用多個視圖，即從一個視圖中選擇產生另一個視圖等。
- 一些視圖連接了三個表，每個表都有大約1-2億行。
- 某些視圖使用子選擇查詢。
到目前為止，我的建議如下：
JOIN處限制資料量，而不是使用WHERE。 例如，不使用select * from tableA JOIN tableB WHERE... , 使用 SELECT * FROM TableA JOIN tableB ON .... AND tableA.date BETWEEN range。 這將在查詢中與其他表連接時提供更少的資料。
問題是他要處理的資料太龐大了，我想知道查詢性能只能做這么多，因為到了最后，你仍然要在查詢中處理所有這些資料。也許下一步是考慮如何準備這些資料，并首先將它們存盤在較小的表中，如CostQ1_2010、CostQ2_2020等，然后根據所有這些表來撰寫你的查詢。
uj5u.com熱心網友回復：
你給我們的資訊非常少。托爾斯泰寫道："所有幸福的家庭都是一樣的；每個不幸福的家庭都有自己不幸福的地方"。這也是SQL查詢的真實情況，尤其是大型BI查詢。
我將冒昧地回答一些一般性問題。
對于你提到的這種規模的表，你的查詢肯定包含日期范圍的WHERE過濾器，比如transaction_date >= something and transaction_date < anotherthing。一般來說，一份有用的報告涵蓋了十年交易中的一年。所以要確保你有正確的索引，盡可能做索引范圍掃描。SSMS，如果你選擇了顯示實際執行計劃功能，有時會建議使用索引。
學會閱讀執行計劃。
閱讀關于覆寫索引的內容。
閱讀關于覆寫索引的文章。
在開始這種長期運行的歷史BI查詢之前，使用陳述句SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED。你將得到BI查詢和資料庫上其他活動之間的較少干擾。
從 BI 查詢中使用的視圖中預加載一些去規范化的表可能是有意義的。
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/309434.html
標籤：