SQL Server索引懷疑

Question

索引用於提高sql查詢的性能，但我總是發現很難決定在哪種情況下應該使用索引，而在哪種情況下不應該使用索引。 我想澄清我對非聚集索引的一些疑問

1. 什么是非聚集索引鍵。 如書所述，非聚集索引的每個索引行都包含非聚集鍵值，所以這意味着它是我們在其中創建非聚集索引的列，即如果在empname varchar（50）上創建索引，則非聚集鍵將是該empname。

2. 為什么最好在寬度較小的列上創建索引。 這是由於與更多寬度的列進行比較會導致SQL Server引擎花費更多時間，或者是由於頁面大小固定時，它將增加中間節點的層次結構，因此頁面所包含的寬度更大的列或節點所包含的索引行會更少。

3. 如果一個表包含多個非聚集列，那么SQL將使用定位器在內部生成指向實際數據行的非聚集鍵是該列的組合，還是某個唯一ID。 如果可能，請清除它，將提供一些實時示例和圖形。

4. 為什么說具有不可重復值的列很適合創建索引，因為即使包含重復值，它也肯定會提高性能，因為一旦達到某個鍵值，其定位器將立即找到其實際行。

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

請參閱任何有助於消除我的疑問的書或教程。

Answer 1

首先，我認為我們需要涵蓋實際的索引。 通常在RDBMS中，索引是使用B樹的變體（最常見的是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的行中akey等於“ some value”，則這意味着在索引以及實際表中都進行了大量查找，以檢索something和something_else的值。 如果此篩選很有可能返回幾行，那么這也意味着較少的磁盤訪問。

5）參見前面的解釋

希望這可以幫助 ：）