選擇爲SQL Server表

Question

最佳指標我有以下結構的SQL Server表：

CREATE TABLE [dbo].[Log](
[LogID] [bigint] IDENTITY(1,1) NOT NULL, 
[A] [int] NOT NULL, 
[B] [int] NOT NULL, 
[C] [int] NOT NULL, 
[D] [int] NOT NULL, 
[E] [int] NOT NULL, 
[Flag1] [bit] NOT NULL, 
[Flag2] [bit] NOT NULL, 
[Flag3] [bit] NOT NULL, 
[Counter] [int] NOT NULL, 
[Start] [datetime] NOT NULL, 
[End] [datetime] NOT NULL) 

表用於記錄活動。列A-E表示外鍵，Flag1-Flag3表示某些日誌狀態，而列Start和End表示標記活動的開始和結束。

平均而言，此表每30秒更新一次，並且更新會產生約50次插入/更新。

用戶可以通過UI進行查詢並過濾任何給定列上的數據以及列和列類型的所有組合。

什麼是優化數據檢索該表的最佳途徑：

1. 創建將持有所有這些列
2. 確定一些最常用的過濾器組合，例如一個「主」指數[A,D,E]，[A, Start, End]等，併爲它們創建索引
3. 別的東西...

Answer 1

我懷疑這裏的任何人都可以做出任何事情，但猜測 - 你需要記錄表的使用情況，並從該用法看到什麼樣的組合被查詢。

1. 創建一個將容納所有這些列

這絕對不是一個好主意，一個 「主」 指數 - 如果你有（A，B，C的指標， D，E），並且通過B和D的值來限制查詢，那個索引完全沒用。如果通過經常

（A，B），（A，B，C），（A，B，C，d）經常

查詢所有五列的組合等等這是唯一有用的

在任何其他情況下，這是一種浪費 - 不要使用它。

1. 確定一些最常用的過濾器組合，例如[A，d，E]，[A， 開始，結束]等，並創建索引 他們

是的，這確實是承諾任何成功的唯一途徑。你需要看看實際發生了什麼樣的查詢，然後調整這些查詢。

Answer 2

一種方法是讓SQL Server的告訴你的最佳使用。運行幾分鐘的痕跡，而該表是在「典型」的用法，然後運行數據庫引擎優化顧問

Answer 3

日誌表很少索引，因爲索引會減慢INSERT，UPDATE和DELETE語句。

我建議任一：

• 加載記錄到表中（臨時的或實際的，索引），使用索引視圖濾波

基本上前 - 如果速度/性能值得關注的是，以另一種形式的表格對記錄進行索引，以便記錄不受影響。

Answer 4

在任何索引組合中，除非外鍵被引用，否則不能使用內鍵。假設你有(A,B,C,D)索引：

• WHERE A=@a AND B=@b AND C=@c AND D=@d將充分利用索引
• WHERE A=@a可能使用索引來過濾行掃描的範圍。 WHERE A=@a AND B=@b,WHERE A=@a AND C=@c等。的最左列（A）的任意組合可能使用索引。
• WHERe B=@b不能使用索引。也不WHERE C=@c,WHERE D=@d和任何其他組合是錯誤A。換句話說，如果列A不在查詢限制中，則索引不可用。

這些是非常基本的規則。除此之外，JOIN條件可以或不可以被視爲與WHERE子句相同。對於較大的結果，未覆蓋指數可能會達到the tipping point。索引不僅可以滿足搜索條件，還可以幫助使用ORDER BY子句。創建的實際索引很大程度上取決於查詢模式，I/O功能，更新負載以及數據大小管理開銷（文件和備份大小的影響）。引擎會給你提示哪些索引可以用於查詢（Missing Indexes feature），但引擎絕不會平衡索引的好處與一個額外索引的成本（I/O，更新性能，數據大小） 。有Index Design Guidelines很好，但當然，你必須通讀它們。最終，選擇合適的指數取決於如此多的因素和考慮因素，這些因素和考慮因素使得曲奇餅的答案不可避免。

Answer 5

我會在開始（日期時間）上放置一個索引，就是這樣，假設對日誌的查詢很少會從最初到現在，而且大部分都是從一個起點出發。