MS Access 2010 SQL Top N 查詢按組性能問題（續）

Question

我在 MS Access 2010 中遇到了嚴重的性能問題（直至超時），並使用以下查詢。 TempTableAnalysis 表包含 10'000-15'000 條記錄。 我已經收到了來自這個論壇的輸入，在前 10 個查詢中使用臨時表（ MS Access 2010 SQL Top N query by group performance issue ）

誰能解釋一下如何在子查詢中實現臨時表以及如何加入它？ 我無法讓它工作。

任何其他提高性能的建議都受到高度贊賞。

這是我的查詢：

SELECT 
t2.Loc, 
t2.ABCByPick, 
t2.Planner, 
t2.DmdUnit, 
ROUND(t2.MASE,2) AS MASE, 
ROUND(t2.AFAR,2) AS AFAR

FROM TempTableAnalysis AS t2

WHERE t2.MASE IN  (
SELECT TOP 10 t1.MASE 
FROM TempTableAnalysis AS t1
WHERE t1.ABCByPick = t2.ABCByPick
ORDER BY t1.MASE DESC
)
ORDER BY
t2.ABCByPick, 
t2.MASE DESC;

Answer 1

優化大數據集的訪問查詢性能

根據您發布的 SQL 查詢，您可以使用一些選項來優化和加快性能。

SELECT 
   t2.Loc, 
   t2.ABCByPick, 
   t2.Planner, 
   t2.DmdUnit, 
   ROUND(t2.MASE,2) AS MASE, 
   ROUND(t2.AFAR,2) AS AFAR

   FROM TempTableAnalysis AS t2
   ...

這是TempTableAnalysis是多千條記錄子查詢的第一部分。 如果你想從使用這個“臨時”表中擠出更多的性能，不要將它用作動態查詢（即，每次打開查詢時按需計算），嘗試構建一個宏來推動輸出到靜態表：

將子查詢數據附加到靜態表：

1. 創建一個QUERY對象並將其類型更改為DELETE 。 設計它以刪除“臨時”表對象的內容。 如果您更喜歡使用 SQL，該命令將如下所示：

    DELETE My_Table.* FROM My_Table;

2. 創建一個QUERY對象並將其類型更改為APPEND 。 將其設計為查詢此 OP 的 SQL 語句定義的查詢中的所有字段。 同樣，此任務的 SQL 版本具有以下語法：

    INSERT INTO StaticAnalysisTable ( ID, Loc, Item, AvgOfScaledError ) SELECT t1.ID, t1.Loc, t1.Item, t1.AvgOfScaledError FROM TempTableAnalysis as t1;

   下一步是自動填充這個靜態表，它是可選的。 然而，這很簡單，並且可以減少您忘記“刷新”並在靜態表具有陳舊數據時訪問靜態表的錯誤......導致結果不准確。

3. 用兩個步驟創建一個宏。 每個步驟都有以下定義： OPEN QUERY 。 當提示打開查詢時，按以下順序引用您在前兩步中創建的對象（重要）： (1) DELETE Query: (your delete query name) then (2) APPEND Query: (your append query name) 。

SQL 查詢注釋和建議

發布的 SQL 查詢的以下部分可以使用一些幫助：

...

WHERE t2.MASE IN  (

     SELECT TOP 10 t1.MASE 
     FROM TempTableAnalysis AS t1
     WHERE t1.ABCByPick = t2.ABCByPick
     ORDER BY t1.MASE DESC
     )

ORDER BY
   t2.ABCByPick, 
   t2.MASE DESC;

1. 在生成 TOP-10 數據的子查詢和將這些結果與補充MASE表數據相關聯的最外層查詢之間存在連接。 如果TempTableAnalysis.MASE表示一個鍵值，則這不是必需的。

2. ORDER BY

   在最內層的查詢中不是必需的，除非它旨在強制某種選擇標准（如使用 SQL 分析函數時），這看起來不像那些情況之一。 從大型數據集中訂購記錄也是一種浪費的 CPU 和內存接收器。

編輯：就像一個反論點一樣，在 TOP N 查詢旁邊使用的ORDER BY子句實際上是有目的的，但我仍然不清楚是否有必要。 只是為了結束討論，另一個 SO 線程討論了如何在訪問查詢中選擇前 10 名。

3. WHERE t2.MASE IN (...

   您可能會遇到非常大的列表內集合操作的性能障礙。 在 Oracle 數據庫服務器上，我與其他開發人員一起發現列表內查詢運算符中的離散元素數量存在限制。 該值以數千計......根據服務器和數據庫資源，這可能會進一步受到限制。

   考慮使用 SQL JOIN運算符。 定義TABLE對象的地方也可以填充 SQL 定義的查詢，別名稱為INLINE VIEWS 。 由於您使用的是 ACCESS，如果內聯視圖不能直接工作，只需定義另一個ACCESS QUERY對象並在您的最終查詢中引用它，就好像它是一個表......

   可能重寫原始查詢的結尾部分：

    SELECT t2.Loc, t2.ABCByPick, t2.Planner, ... FROM TempTableAnalysis AS t2, (SELECT TOP 10 t1.MASE, t1.ABCByPick FROM TempTableAnalysis AS t1) AS ttop WHERE t2.MASE = ttop.MASE AND t2.ABCByPick = ttop.ABCByPick ORDER BY t2.ABCByPick, t2.MASE DESC;

您肯定需要執行這些建議並驗證輸出數據的准確性。 這代表了捕獲一些“容易實現的目標”（簡單項目）的方法，您可以通過這些方法來加速查詢和報告操作。

結論和結束語

作為其他讀者的背景，數據庫對象TempTableAnalysis不是靜態表。 這是另一個 SO 帖子中出現的子查詢的結果，該帖子請求Access TOP N Query 的幫助。 查詢來自多個表，大小接近 10,000 條記錄（每個？）。

提示： Access 中的查詢結果也具有潛在的類似表格的行為。 您可以將輸出推送到表以進行連接（如上所述）或僅連接到查詢對象本身（但要小心，尤其是當您“鏈接”多個查詢操作時......）

該解決方案的策略是：

1. 盡量減少通過這個非常大的表的一個或多個實例的次數。

2. 預處理和索引優化任何在其分析期間本來是“靜態”的數據。

3. 審計和審查用於獲得最終結果的 SQL 代碼。

絕對查看訪問宏。 再加上識別數據集中的靜態數據，您可以卸載復雜后台分析查詢的處理，以改善用戶查看和查詢最終結果時的體驗。 祝你好運！