Sql-Server
優化建議的可疑重複索引
請注意複合主鍵。這樣做有 3 個原因:
- 防止重複條目
- 提高查詢性能,因為所有查詢都將擁有 3 個鍵。
- 我們需要和索引,我不想引入隨機 ID。
另請注意,此表的設計考慮了其大小,此表將儲存數百萬行數據。
現在可以回答我的實際問題了。我正在使用 azure sql server 來託管這個數據庫。我已經啟用了自動調整。奇怪的是,我看到它然後創建了一個新索引。(見下文)
現在在我看來,這似乎是一個重複的索引,因為正在索引相同的列。
所以現在我的桌子上有兩個索引:
原創(我的PK):
ALTER TABLE [dbo].[SensorDataRaw] ADD CONSTRAINT [PK_SensorDataRaw] PRIMARY KEY CLUSTERED ( [DateTime] ASC, [SensorId] ASC, [Key] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) GO
新增(由 azure 調整自動創建):
CREATE NONCLUSTERED INDEX [nci_wi_SensorDataRaw_DC9789077DA75B4440AC8BFE3E2AA198] ON [dbo].[SensorDataRaw] ( [Key] ASC, [SensorId] ASC, [DateTime] ASC ) INCLUDE ( [Value]) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) GO
觀察:
- 新索引中的列順序已顛倒。
- 新索引不是唯一的
- 新索引包括 value 列。
請注意,我對索引的了解並不先進,因此我問這個。
所以我的問題是:
- 有人可以解釋為什麼新添加的索引比我最初創建的索引更好。
- 如何刪除這兩個索引並只創建一個涵蓋這兩種情況的索引。由於這是一個如此龐大的數據庫,我無法承受這兩個索引所佔用的空間。
- 也許是更好的設計替代方案?
附加資訊:
我假設查詢的類型在這裡變得很重要,所以我列出了一些例子。
所有查詢包括
DateTime
、SensorId
和Key
。簡單查詢:
Select SensorId Where average value for key w is greater than x where time between (y,z)
繪圖數據:
SELECT AVG([Value]) AS 'AvgValue', DATEADD( MINUTE, (DATEDIFF(MINUTE, '1990-01-01T00:00:00', [dbo].[SensorDataRaw]. [DateTime]) / @IntervalInMinutes) * @IntervalInMinutes, '1990-01-01T00:00:00' ) AS 'TimeGroup' FROM [dbo].[SensorDataRaw] where [dbo].[SensorDataRaw].[SensorId] = @SensorId and [dbo].[SensorDataRaw].[Key] = @KeyValue and [dbo].[SensorDataRaw].[DateTime] Between @DateFrom and @DateTo and [dbo].[SensorDataRaw].[Value] IS NOT NULL GROUP BY (DATEDIFF(MINUTE, '1990-01-01T00:00:00', [dbo].[SensorDataRaw]. [DateTime]) / @IntervalInMinutes)
系統建議的索引更適合您顯示的查詢。您的目標應該是將具有相等謂詞的列作為前導列。
考慮由 訂購的電話簿
lastname, firstname
。如果您的要求是查找所有姓氏介於“Brown”和“Yates”之間且名字為“John”的人,那麼您需要閱讀大部分電話簿。如果電話簿是由您訂購的,firstname, lastname
您可以輕鬆找到“John”部分和該部分中的第一個“Brown”,那麼您需要做的就是閱讀所有名稱,直到lastname
“Yates”之後或遇到新的名字。它可能不是理想的索引。您可能應該只將聚集索引中的鍵列更改為此順序,而不是創建一個新的。您需要根據對工作量的了解來評估這一點。