優化的選擇

執行我想優化這個選擇：優化的選擇

Select Dane1, Dane5, Dane6, Dane7 FROM Test 
INNER JOIN Test2 ON Test.Id=Test2.IdTest 
WHERE Dane5 > 199850

我的數據庫有2個表測試，測試2：

試驗設計： ID INT - > PRIMARY KEY， Dane1 INT ， Dane2 INT， Dane3 INT， Dane4 INT， Dane5 INT，

TEST2設計： ID INT - > PRIMARY KEY， Dane6 INT， Dane7 INT， IdTest INT，

默認索引： PK__test__7C8480AE（羣集），PK__test2__7E6CC920（羣集）

的問題是：要附加或刪除哪些索引？

也告訴我們聚集索引中的列。默認情況下，它們將是您的主鍵，但也許您沒有默認設置？我們無法從自動生成的羣集名稱中推斷出任何內容：P – Kritner

羣集索引位於主鍵上：測試表中的Id和測試2表上的Id。 –

有創建索引時，要考慮例如幾件事情在這種情況下：

你可以嘗試這樣的事：

Create index test_xxx on test (Dane5) include (Dane1)

天氣，包括Dane1取決於有多少行有，如果鍵查找是造成問題

ID已包括在內，因爲它聚集指數

Create index test2_yyy on test2 (IdTest) include (Dane6, Dane7)

天氣有Dane6和Date7爲包含的列這裏也取決於總amou需要對錶進行鍵查找以獲得它們

您應該打開統計信息io來查看導致最多邏輯讀取的內容，以及天氣中索引中包含的列是否需要。

2015-06-15 15:45:05

定義foreign-key relationships總是一個好主意。這樣，您可以保持數據完整性，並且可以指定在刪除父記錄時發生的情況（即，遞歸地刪除子節點）。

外鍵也是index快速查找子記錄的好候選。

2015-06-15 15:08:20

正如Tim指出的那樣，在外鍵上定義的外鍵和索引是一個很好的調用。

，可以給你一些額外的速度還有一個額外的指數 - 假設你where子句總是要上Dane5 - 是對Dane5

添加非聚集索引

2015-06-15 15:15:49 Kritner

我已經定義了外鍵，並在Dane5上添加了一個非聚簇索引，但估計子樹代碼比之前更糟：4,96352之後：4,9659爲什麼？ –

以及......「估計」是以度量標準的名義 - 不一定把它看作是其他任何東西。可以非常棘手 - 他們可以幫助一些查詢而傷害其他人。我一直認爲它們更像是一門藝術而不是科學，儘管肯定涉及科學。只需要測試和調整。也許這只是我，但：D – Kritner

回答