SQL索引在資料庫優化中佔有一個非常大的比例， 一個好的索引的設計，可以讓你的效率提高几十甚至幾百倍，在這裡將帶你一步步揭開他的神祕面紗。

　　1.1 什麼是索引？

　　SQL索引有兩種，聚集索引和非聚集索引，索引主要目的是提高了SQL Server系統的效能，加快資料的查詢速度與減少系統的響應時間 

下面舉兩個簡單的例子：

圖書館的例子：一個圖書館那麼多書，怎麼管理呢？建立一個字母開頭的目錄，例如：a開頭的書，在第一排，b開頭的在第二排，這樣在找什麼書就好說了，這個就是一個聚集索引，可是很多人借書找某某作者的，不知道書名怎麼辦？圖書管理員在寫一個目錄，某某作者的書分別在第幾排，第幾排，這就是一個非聚集索引

字典的例子：字典前面的目錄，可以按照拼音和部首去查詢，我們想查詢一個字，只需要根據拼音或者部首去查詢，就可以快速的定位到這個漢字了，這個就是索引的好處，拼音查詢法就是聚集索引，部首查詢就是一個非聚集索引.

    看了上面的例子，下面的一句話大家就很容易理解了：聚集索引儲存記錄是物理上連續存在，而非聚集索引是邏輯上的連續，物理儲存並不連續。就像欄位，聚集索引是連續的，a後面肯定是b，非聚集索引就不連續了，就像圖書館的某個作者的書，有可能在第1個貨架上和第10個貨架上。還有一個小知識點就是：聚集索引一個表只能有一個，而非聚集索引一個表可以存在多個。

　　　1.2 索引的儲存機制

  　　首先，無索引的表，查詢時，是按照順序存續的方法掃描每個記錄來查詢符合條件的記錄，這樣效率十分低下,舉個例子，如果我們將字典的漢字隨即打亂，沒有前面的按照拼音或者部首查詢，那麼我們想找一個字，按照順序的方式去一頁頁的找，這樣效率有多底，大家可以想象。

       聚集索引和非聚集索引的根本區別是表記錄的排列順序和與索引的排列順序是否一致，其實理解起來非常簡單，還是舉字典的例子：如果按照拼音查詢，那麼都是從a-z的，是具有連續性的，a後面就是b，b後面就是c， 聚集索引就是這樣的，他是和表的物理排列順序是一樣的，例如有id為聚集索引，那麼1後面肯定是2,2後面肯定是3，所以說這樣的搜尋順序的就是聚集索引。非聚集索引就和按照部首查詢是一樣是，可能按照偏房查詢的時候，根據偏旁‘弓’字旁，索引出兩個漢字，張和弘，但是這兩個其實一個在100頁，一個在1000頁，（這裡只是舉個例子），他們的索引順序和資料庫表的排列順序是不一樣的，這個樣的就是非聚集索引。

      原理明白了，那他們是怎麼儲存的呢？在這裡簡單的說一下，聚集索引就是在資料庫被開闢一個物理空間存放他的排列的值，例如1-100，所以當插入資料時，他會重新排列整個整個物理空間，而非聚集索引其實可以看作是一個含有聚集索引的表，他只僅包含原表中非聚集索引的列和指向實際物理表的指標。他只記錄一個指標，其實就有點和堆疊差不多的感覺了

　　1.3 什麼情況下設定索引 

建立索引的原則：

1) 定義主鍵的資料列一定要建立索引。

2) 定義有外來鍵的資料列一定要建立索引。

3) 對於經常查詢的資料列最好建立索引。

4) 對於需要在指定範圍內的快速或頻繁查詢的資料列;

5) 經常用在WHERE子句中的資料列。

6) 經常出現在關鍵字order by、group by、distinct後面的欄位，建立索引。如果建立的是複合索引，索引的欄位順序要和這些關鍵字後面的欄位順序一致，否則索引不會被使用。

7) 對於那些查詢中很少涉及的列，重複值比較多的列不要建立索引。

8) 對於定義為text、image和bit的資料型別的列不要建立索引。

9) 對於經常存取的列避免建立索引 

9) 限制表上的索引數目。對一個存在大量更新操作的表，所建索引的數目一般不要超過3個，最多不要超過5個。索引雖說提高了訪問速度，但太多索引會影響資料的更新操作。

10) 對複合索引，按照欄位在查詢條件中出現的頻度建立索引。在複合索引中，記錄首先按照第一個欄位排序。對於在第一個欄位上取值相同的記錄，系統再按照第二個欄位的取值排序，以此類推。因此只有複合索引的第一個欄位出現在查詢條件中，該索引才可能被使用,因此將應用頻度高的欄位，放置在複合索引的前面，會使系統最大可能地使用此索引，發揮索引的作用。

　　1.4 如何建立索引

　1.41 建立索引的語法：

CREATE [UNIQUE][CLUSTERED | NONCLUSTERED]  INDEX  index_name  

ON {table_name | view_name} [WITH [index_property [,....n]]

說明：

UNIQUE: 建立唯一索引。

CLUSTERED: 建立聚集索引。

NONCLUSTERED: 建立非聚集索引。

Index_property: 索引屬性。

 UNIQUE索引既可以採用聚集索引結構，也可以採用非聚集索引的結構，如果不指明採用的索引結構，則SQL Server系統預設為採用非聚集索引結構。

1.42 刪除索引語法：

DROP INDEX table_name.index_name[,table_name.index_name]

說明：table_name: 索引所在的表名稱。

index_name : 要刪除的索引名稱。

1.43 顯示索引資訊：

使用系統儲存過程：sp_helpindex 檢視指定表的索引資訊。

執行程式碼如下：

Exec sp_helpindex book1;

　　1.5 索引使用次數、索引效率、佔用CPU檢測、索引缺失

　　當我們明白了什麼是索引，什麼時間建立索引以後，我們就會想，我們建立的索引到底效率執行的怎麼樣？好不好？我們建立的對不對？

　　首先我們來認識一下DMV，DMV (dynamic management view)動態管理檢視和函式返回特定於實現的內部狀態資料。推出SQL Server 2005時，微軟介紹了許多被稱為dmvs的系統檢視，讓您可以探測SQL Server 的健康狀況，診斷問題，或檢視SQL Server例項的執行資訊。統計資料是在SQL Server執行的時候開始收集的，並且在SQL Server每次啟動的時候，統計資料將會被重置。當你刪除或者重新建立其元件時，某些dmv的統計資料也可以被重置，例如儲存過程和表，而其它的dmv資訊在執行dbcc命令時也可以被重置。

　　當你使用一個dmv時，你需要緊記SQL Server收集這些資訊有多長時間了，以確定這些從dmv返回的資料到底有多少可用性。如果SQL Server只運行了很短的一段時間，你可能不想去使用一些dmv統計資料，因為他們並不是一個能夠代表SQL Server例項可能遇到的真實工作負載的樣本。另一方面，SQL Server只能維持一定量的資訊，有些資訊在進行SQL Server效能管理活動的時候可能丟失，所以如果SQL Server已經運行了相當長的一段時間，一些統計資料就有可能已被覆蓋。

　　因此，任何時候你使用dmv，當你檢視從SQL Server 2005的dmvs返回的相關資料時，請務必將以上的觀點裝在腦海中。只有當你確信從dmvs獲得的資訊是準確和完整的，你才能變更資料庫或者應用程式程式碼。

下面就看一下dmv到底能帶給我們那些好的功能呢？

1.51 ：索引使用次數

我們下看一下下面兩種查詢方式返回的結果（這兩種查詢的查詢用途一致）

①----

declare @dbid int

select @dbid = db_id()

select objectname=object_name(s.object_id), s.object_id, indexname=i.name, i.index_id

            , user_seeks, user_scans, user_lookups, user_updates

from sys.dm_db_index_usage_stats s,

            sys.indexes i

where database_id = @dbid and objectproperty(s.object_id,'IsUserTable') = 1

and i.object_id = s.object_id

and i.index_id = s.index_id

order by (user_seeks + user_scans + user_lookups + user_updates) asc

返回查詢結果

②：使用多的索引排在前面

SELECT  objects.name ,

        databases.name ,

        indexes.name ,

        user_seeks ,

        user_scans ,

        user_lookups ,

        partition_stats.row_count

FROM    sys.dm_db_index_usage_stats stats

        LEFT JOIN sys.objects objects ON stats.object_id = objects.object_id

        LEFT JOIN sys.databases databases ON databases.database_id = stats.database_id

        LEFT JOIN sys.indexes indexes ON indexes.index_id = stats.index_id

                                         AND stats.object_id = indexes.object_id

        LEFT  JOIN sys.dm_db_partition_stats partition_stats ON stats.object_id = partition_stats.object_id

                                                              AND indexes.index_id = partition_stats.index_id

WHERE   1 = 1

--AND databases.database_id = 7

        AND objects.name IS NOT NULL

        AND indexes.name IS NOT NULL

        AND user_scans>0

ORDER BY user_scans DESC ,

        stats.object_id ,

        indexes.index_id

返回查詢結果

user_seeks : 通過使用者查詢執行的搜尋次數。 
 個人理解： 此統計索引搜尋的次數

user_scans: 通過使用者查詢執行的掃描次數。 
  個人理解：此統計表掃描的次數，無索引配合
user_lookups: 通過使用者查詢執行的查詢次數。 
 個人理解：使用者通過索引查詢，在使用RID或聚集索引查詢資料的次數，對於堆表或聚集表資料而言和索引配合使用次數
user_updates:  通過使用者查詢執行的更新次數。 
  個人理解：索引或表的更新次數

我們可以清晰的看到，那些索引用的多，那些索引沒用過，大家可以根據查詢出來的東西去分析自己的資料索引和表

1.52 ：索引提高了多少效能

新建了索引到底增加了多少資料的效率呢？到底提高了多少效能呢？執行如下SQL可以返回連線缺失索引動態管理檢視，發現最有用的索引和建立索引的方法： 

SELECT  

avg_user_impact AS average_improvement_percentage,  

avg_total_user_cost AS average_cost_of_query_without_missing_index,  

'CREATE INDEX ix_' + [statement] +  

ISNULL(equality_columns, '_') + 

ISNULL(inequality_columns, '_') + ' ON ' + [statement] +  

' (' + ISNULL(equality_columns, ' ') +  

ISNULL(inequality_columns, ' ') + ')' +  

ISNULL(' INCLUDE (' + included_columns + ')', '')  

AS create_missing_index_command 

FROM sys.dm_db_missing_index_details a INNER JOIN  

sys.dm_db_missing_index_groups b ON a.index_handle = b.index_handle 

INNER JOIN sys.dm_db_missing_index_group_stats c ON  

b.index_group_handle = c.group_handle 

WHERE avg_user_impact > = 40

返回結果

雖然使用者能夠修改效能提高的百分比，但以上查詢返回所有能夠將效能提高40%或更高的索引。你可以清晰的看到每個索引提高的效能和效率了

1.53 ：最佔用CPU、執行時間最長命令

這個和索引無關，但是還是在這裡提出來，因為他也屬於DMV帶給我們的功能嗎，他可以讓你輕鬆查詢出，那些sql語句佔用你的cpu最高

SELECT TOP 100 execution_count,

           total_logical_reads /execution_count AS [Avg Logical Reads],

           total_elapsed_time /execution_count AS [Avg Elapsed Time],

                db_name(st.dbid) as [database name],

           object_name(st.dbid) as [object name],

           object_name(st.objectid) as [object name 1],

           SUBSTRING(st.text, (qs.statement_start_offset / 2) + 1, 

           ((CASE statement_end_offset WHEN - 1 THEN DATALENGTH(st.text) ELSE qs.statement_end_offset END - qs.statement_start_offset) 

             / 2) + 1) AS statement_text

  FROM sys.dm_exec_query_stats AS qs CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS st

 WHERE execution_count > 100

 ORDER BY 1 DESC;

返回結果：

執行時間最長的命令

SELECT TOP 10 COALESCE(DB_NAME(st.dbid),

DB_NAME(CAST(pa.value as int))+'*',

'Resource') AS DBNAME,

SUBSTRING(text,

-- starting value for substring

        CASE WHEN statement_start_offset = 0

OR statement_start_offset IS NULL

THEN 1

ELSE statement_start_offset/2 + 1 END,

-- ending value for substring

        CASE WHEN statement_end_offset = 0

OR statement_end_offset = -1

OR statement_end_offset IS NULL

THEN LEN(text)

ELSE statement_end_offset/2 END -

CASE WHEN statement_start_offset = 0

OR statement_start_offset IS NULL

THEN 1

ELSE statement_start_offset/2  END + 1

)  AS TSQL,

total_logical_reads/execution_count AS AVG_LOGICAL_READS

FROM sys.dm_exec_query_stats

CROSS APPLY sys.dm_exec_sql_text(sql_handle) st

OUTER APPLY sys.dm_exec_plan_attributes(plan_handle) pa

WHERE attribute = 'dbid'

ORDER BY AVG_LOGICAL_READS DESC ;

看到了嗎？直接可以定位到你的sql語句，優化去吧。還等什麼呢？

1.54：缺失索引

缺失索引就是幫你查詢你的資料庫缺少什麼索引，告訴你那些欄位需要加上索引，這樣你就可以根據提示新增你資料庫缺少的索引了

SELECT TOP 10

[Total Cost] = ROUND(avg_total_user_cost * avg_user_impact * (user_seeks + user_scans),0)

, avg_user_impact

, TableName = statement

, [EqualityUsage] = equality_columns

, [InequalityUsage] = inequality_columns

, [Include Cloumns] = included_columns

FROM    sys.dm_db_missing_index_groups g

INNER JOIN sys.dm_db_missing_index_group_stats s

ON s.group_handle = g.index_group_handle

INNER JOIN sys.dm_db_missing_index_details d

ON d.index_handle = g.index_handle

ORDER BY [Total Cost] DESC;

查詢結果如下：

　　1.6  適當建立索引覆蓋

　　假設你在Sales表(SelesID,SalesDate,SalesPersonID,ProductID,Qty)的外來鍵列(ProductID)上建立了一個索引，假設ProductID列是一個高選中性列，那麼任何在where子句中使用索引列(ProductID)的select查詢都會更快，如果在外來鍵上沒有建立索引，將會發生全部掃描，但還有辦法可以進一步提升查詢效能。

　　假設Sales表有10,000行記錄，下面的SQL語句選中400行(總行數的4%)：　

SELECT SalesDate, SalesPersonID FROM Sales WHERE ProductID = 112

　　我們來看看這條SQL語句在SQL執行引擎中是如何執行的：

　　1)Sales表在ProductID列上有一個非聚集索引，因此它查詢非聚集索引樹找出ProductID=112的記錄;

　　2)包含ProductID = 112記錄的索引頁也包括所有的聚集索引鍵(所有的主鍵鍵值，即SalesID);

　　3)針對每一個主鍵(這裡是400)，SQL Server引擎查詢聚集索引樹找出真實的行在對應頁面中的位置;

　　SQL Server引擎從對應的行查詢SalesDate和SalesPersonID列的值。

　　在上面的步驟中，對ProductID = 112的每個主鍵記錄(這裡是400)，SQL Server引擎要搜尋400次聚集索引樹以檢索查詢中指定的其它列(SalesDate，SalesPersonID)。

　　如果非聚集索引頁中包括了聚集索引鍵和其它兩列(SalesDate,，SalesPersonID)的值，SQL Server引擎可能不會執行上面的第3和4步，直接從非聚集索引樹查詢ProductID列速度還會快一些，直接從索引頁讀取這三列的數值。

　　幸運的是，有一種方法實現了這個功能，它被稱為“覆蓋索引”，在表列上建立覆蓋索引時，需要指定哪些額外的列值需要和聚集索引鍵值(主鍵)一起儲存在索引頁中。下面是在Sales 表ProductID列上建立覆蓋索引的例子：　

CREATE INDEX NCLIX_Sales_ProductID--Index name

　　ON dbo.Sales(ProductID)--Column on which index is to be created
　　INCLUDE(SalesDate, SalesPersonID)--Additional column values to include

　　應該在那些select查詢中常使用到的列上建立覆蓋索引，但覆蓋索引中包括過多的列也不行，因為覆蓋索引列的值是儲存在記憶體中的，這樣會消耗過多記憶體，引發效能下降。

　　1.7 索引碎片

　　1.8 索引實戰（摘抄）

之所以這章摘抄，是因為下面這個文章已經寫的太好了，估計我寫出來也無法比這個好了，所以就摘抄了

人們在使用SQL時往往會陷入一個誤區，即太關注於所得的結果是否正確，而忽略了不同的實現方法之間可能存在的效能差異，這種效能差異在大型的或是複雜的資料庫環境中（如聯機事務處理OLTP或決策支援系統DSS）中表現得尤為明顯。

筆者在工作實踐中發現，不良的SQL往往來自於不恰當的索引設計、不充份的連線條件和不可優化的where子句。

在對它們進行適當的優化後，其執行速度有了明顯地提高！

下面我將從這三個方面分別進行總結：

為了更直觀地說明問題，所有例項中的SQL執行時間均經過測試，不超過１秒的均表示為（< 1秒）。----

測試環境: 主機：HP LH II---- 主頻：330MHZ---- 記憶體：