2012-01-14 125 views
0

索引用於提高sql查詢的性能,但我總是覺得很難決定在哪種情況下應該使用索引,哪些情況不適用。我想澄清一些關於非聚集索引我的疑惑SQL Server索引疑問

  1. 什麼叫非聚集索引鍵。正如書中所說,非聚簇索引的每個索引行都包含非聚簇鍵值,因此這意味着它是我們在其中創建非聚簇索引的列,即如果在empname varchar(50)上創建索引,則非聚簇鍵將爲 ,即empname 。

  2. 爲什麼最好在小寬度的列上創建索引。這是由於與更多寬度列進行比較需要更多時間用於SQL Server引擎,還是因爲它會增加中間節點的層次結構,因爲頁面大小是固定的,因此頁面中的寬度列或節點中包含的索引行更少。

  3. 如果一個表包含多個非聚集列,以便非聚集鍵是否將組合所有此列或某些唯一ID由SQL內部生成,而定位器將指向實際的數據行。如果可能的話請清除一些實時的示例和圖表。

  4. 爲什麼據說具有不可重複值的列可以很好地創建索引,即使它包含重複值,它肯定會提高性能,因爲一旦它達到某個鍵值,其定位器將立即找到其實際行。

  5. 如果在索引中使用的列不是唯一的,它如何從表中找到實際的數據行。

請參考任何書籍或教程,這將是有用的清除我的疑慮。

回答

0

首先,我認爲我們需要涵蓋實際指數。通常在RDBMS中使用變體B-tree's(B +變體是最常見的)來實現索引。簡而言之 - 認爲一個優化的二叉搜索樹被存儲在磁盤上。在B樹中查找關鍵字的結果通常是表的主鍵。這意味着如果索引中的查找完成並且我們需要比索引中存在更多的數據,那麼我們可以使用主鍵在表中進行查找。

請記住,當我們考慮RDBMS的性能時,我們通常會在磁盤訪問(我決定忽略鎖定和其他問題)和CPU時間不足的情況下對此進行度量。

具有被非聚集的索引意味着在表中的數據被存儲在實際的方式沒有任何關係的索引關鍵字 - 而聚集索引指定在表中的數據將被排序(或羣集)索引鍵 - 這就是爲什麼每個表只能有一個聚集索引的原因。 2)回到我們的衡量性能模型 - 如果索引關鍵字的寬度很小(適合少量的字節),這意味着我們檢索的每塊磁盤數據塊都可以容納更多的關鍵字,如果您測量磁盤I/O,則可以更快地在B樹中執行查找。

3)我試着進一步解釋這一點 - 不幸的是,我沒有任何圖表或圖紙來表明這一點 - 希望別人可以來分享這些。

4)如果你正在運行像這樣的查詢:

SELECT something, something_else FROM sometable t1 WHERE akey = 'some value' 

在一個表像這樣定義的索引:

CREATE INDEX idx_sometable_akey ON sometable(akey) 

如果sometable有很多行,其中A鑰等於爲了「某種價值」,這意味着在索引中的大量查找,而且在實際的表中檢索東西和something_else的值。而如果這個過濾很有可能返回幾行,那麼它也意味着更少的磁盤訪問。

5)請參見前面的解釋

希望這有助於:)

+0

非常感謝。你的文章給我很清楚的瞭解索引 – user1149555 2012-01-14 18:40:52

+0

請清除我的觀點如何在內部維護複合非聚集索引SQL Server – user1149555 2012-01-15 03:15:58

+0

昨天我發佈這個視頻後,我發現這個視頻/演示文稿刪除了大量的技術細節(B-樹的等等),並且純粹地展示瞭如何使用索引來加速查詢:http://vimeo.com/26454091 - 它還顯示了聚類和非聚類索引之間的區別。 – kastermester 2012-01-15 14:39:30