SQL Server 2005中的“索引”（也稱為維護表）聚合數據

Question

我有一個維護系統性能數據的表，每個記錄都是對某個重要方法的調用，並由方法名稱，其持續時間和令牌組成-對系統的每個請求都賦予一個唯一的令牌，因此所有具有相同令牌的記錄是相同的請求，例如：

CallName    Duration    Token
----------- ----------- -----------
GetData     121         12345
Process     800         12345
SaveData    87          12345

GetData     97          ABCDE
Process     652         ABCDE
SaveData    101         ABCDE

我對按令牌和CallName分組的匯總數據感興趣，例如：

-- The total duration of each request, in descending order
SELECT Token, SUM(Duration) FROM Requests GROUP BY Token ORDER BY SUM(Duration) DESC

-- The average duration of each call, in descending order
SELECT CallName, AVG(Duration) FROM Requests GROUP BY CallName ORDER BY AVG(Duration) DESC

現在，該表可能非常大，並且我只會對每個查詢的前幾條記錄感興趣，因此我為這兩個查詢實現了分頁。 問題在於，由於這些查詢涉及聚合函數，因此SQL Server最終還是要進行表掃描。

肯定其他人以前有這個問題嗎？

我真正需要的是按令牌分組的SUM（Duration）的“索引”，即可以在其中執行以下操作的表：

SELECT Token, SumToken FROM RequestTokens ORDER BY SumToken DESC

• 這真的是個壞主意嗎？
• 如果是這樣，有沒有更好的方法？
• 最好的方法是什么？ INSERT / UPDATE / DELETE上的觸發器是否可以工作（我根據舊值和更改后的數據更新匯總值），還是在更新此表時手動更新“索引”更好？

觸發器是到目前為止我提出的最好的解決方案，但是我已經可以看到這是一個僵局/一致性噩夢！ ：-S

Answer 1

可能基於聚合的視圖，甚至可能是索引視圖。 對於索引視圖，我還沒有做太多事情，但是本文討論了如何將它們與像AVG（）這樣的復雜聚合一起使用。 也許它將為您提供正確的方向。

http://msdn.microsoft.com/zh-CN/library/aa933148%28SQL.80%29.aspx

Answer 2

首先，Token列上的索引是否足夠？ 這樣，給定Token值，SQL查詢優化器將僅掃描包含您感興趣的行的那部分索引。將其設為聚集索引，您將獲得最佳性能。

接下來，您如何知道您對匯總哪個令牌值感興趣？ 沒有列出日期時間（或時間戳）列，並且令牌值似乎是隨機分配的（與某種形式的升值相對），因此我猜您在發出查詢之前就知道要匯總的令牌值-在哪個索引中應該做你想要的。 如果值未知但以某種方式遞增，則可以使用許多策略來首先確定最新的X令牌值，一旦獲得了這些令牌，您將返回部分表掃描。

Answer 3

現在，我對它有了進一步的了解，因此我將再次嘗試。 這是一個不常見的報告問題，導致出現了數據倉庫解決方案，例如：您是否可以僅添加第二個包含預聚合數據的表？ 這的確是非規范化/冗余數據……但看起來清晰且定義明確，可以滿足業務需求。 在這個想法上有一些皺紋：

如果僅輸入一次數據，則可以修改數據輸入例程以同時添加聚合的行。 如果隨着時間的流逝而滴入，您將需要重復執行的過程來“清掃一切”。 我避免基於一般原理觸發； 他們可能會在這里有所幫助，但它們也可能會根據使用模式和數據相互關系來捆綁您的系統。

數據必須是最新的？ 匯總數據可以與詳細數據不同步嗎？如果可以，請保持多長時間？ 您可能有一個每天/每小時/ 5分鍾運行的SQL Agent作業，以掃描最近的條目並更新聚合表。 （添加索引的“最后輸入”列，這些更新可能很快。）折衷是您的數據將關閉的時間段。 （但是datetime列可能指示“直到何時”數據是正確的。也許您在那個時間點之后不提供匯總數據？）

如果輸入后數據沒有更改（沒有更新，沒有刪除，沒有遲到行），這可以工作-但是如果您必須隨着時間的推移維護更新，並且匯總數據更改必須在在輸入數據的同時，這可能是一場噩夢。