索引總和列

Question

正在爲正在求和的列創建索引比沒有索引快嗎？

Answer 1

對不起，你不清楚你在問什麼。

你是問，如果添加數量上的指標，將加快這種查詢的

SELECT product, sum(quantity) FROM receipts 
GROUP BY product 

？

如果這是問題，那麼答案是否定的。一般來說，當你需要在很多行中找到幾行時，索引是有幫助的;在這裏你需要所有的行，所以索引沒有幫助。

有一個模糊的異常（很少適用於大多數數據庫優化器可能不會執行此技巧）。如果查詢恰好是

SELECT sum(foo) FROM bar 

，那裏是於foo的一個指標，酒吧是很多列的表，可以在完整的索引讀取，招致比如果你讀了一個較小的命中底層表，並直接從索引中獲得答案 - 根本不必觸摸「真實」表！然而，這是一個相當少見的情況，你需要測試你的優化器是否知道這麼做，然後才依賴於這個。

Answer 2

編號索引通過限制需要多少次檢查來改善搜索。無論如何，彙總函數（count，max，min，sum，avg）都必須遍歷列中的所有條目。

Answer 3

如果您希望加快求和速度，可以預先實現結果。在Oracle上，使用Materialized Views，在MS SQL上使用Indexed Views。

您的具體問題「是創造正被總結一列的索引比沒有索引快？」，答案是否定的

的回答你的問題在於對斯賓塞的回答是：

「彙總函數（計數，最大值，最小值，總和，平均值）必須遍歷列中的所有條目進行求和，無論如何。」

剛剛澄清了斯賓塞答案中列的上下文。儘管如此，他的回答是正確的。

Answer 4

如果索引覆蓋，它通常會更快。表格中的列數與索引中的數字之間的差異將決定更快的速度。另外，如果有任何過濾標準，它可能會更快。

Answer 5

我發現索引使用此查詢時，在其中一列（這裏的ProductID）幫助：

SELECT的ProductID，SUM（數量）收到來自WHERE的ProductID = 1 GROUP BY的productid

我的一個查詢一旦我添加索引，就從45秒變爲幾乎瞬間。