北京北大青鳥學術部提供：
假設你想找到本書中的某一個句子。你可以一頁一頁地逐頁搜索，但這會花很時間。而通過使用本書的索引，你可以很快地找到你要搜索的主題。表的索引與附在一本書后面的索引非常相似。它可以極大地提高查詢的速度。對一個較大的表來說，通過加索引，一個通常要花費幾個小時來完成的查詢只要幾分鐘就可以完成。
因此沒有理由對需要頻繁查詢的表增加索引。
注意：
當你的內存容量或硬盤空間不足時，也許你不想給一個表增加索引。對于包含索引的數據庫，SQL Sever 需要一個可觀的額外空間。例如，要建立一個聚簇索引，需要大約１.２倍于數據大小的空間。要看一看一個表的索引在數據庫中所占的空間大小，你可以使用系統存儲過程sp_spaceused，對象名指定為被索引的表名。
聚簇索引和非聚簇索引（北京北大青鳥）
假設你已經通過本書的索引找到了一個句子所在的頁碼。一旦已經知道了頁碼后，你很可能漫無目的翻尋這本書，直至找到正確的頁碼。通過隨機的翻尋，你最終可以到達正確的頁碼。但是，有一種找到頁碼的更有效的方法。
首先，把書翻到大概一半的地方，如果要找的頁碼比半本書處的頁碼小，就書翻到四分之一處，否則，就把書翻到四分之三的地方。通過這種方法，你可以繼續把書分成更小的部分，直至找到正確的頁碼附近。這是找到書頁的非常有效的一種方法。
SQL Sever 的表索引以類似的方式工作。一個表索引由一組頁組成，這些頁構成了一個樹形結構。根頁通過指向另外兩個頁，把一個表的記錄從邏輯上分成和兩個部分。而根頁所指向的兩個頁又分別把記錄分割成更小的部分。每個頁都把記錄分成更小的分割，直至到達葉級頁。
索引有兩種類型：聚簇索引和非聚簇索引。在聚簇索引中，索引樹的葉級頁包含實際的數據：記錄的索引順序與物理順序相同。在非聚簇索引中，葉級頁指向表中的記錄：記錄的物理順序與邏輯順序沒有必然的聯系。
聚簇索引非常象目錄表，目錄表的順序與實際的頁碼順序是一致的。非聚簇索引則更象書的標準索引表，索引表中的順序通常與實際的頁碼順序是不一致的。一本書也許有多個索引。例如，它也許同時有主題索引和作者索引。同樣，一個表可以有多個非聚簇索引。通常情況下，你使用的是聚簇索引，但是你應該對兩種類型索引的優缺點都有所理解。每個表只能有一個聚簇索引，因為一個表中的記錄只能以一種物理順序存放。通常你要對一個表按照標識字段建立聚簇索引。但是，你也可以對其它類型的字段建立聚簇索引，如字符型，數值型和日期時間型字段。從建立了聚簇索引的表中取出數據要比建立了非聚簇索引的表快。當你需要取出一定范圍內的數據時，用聚簇索引也比用非聚簇索引好。例如，假設你用一個表來記錄訪問者在你網點上的活動。如果你想取出在一定時間段內的登錄信息，你應該對這個表的DATETIME 型字段建立聚簇索引。
對聚簇索引的主要限制是每個表只能建立一個聚簇索引。但是，一個表可以有不止一個非聚簇索引。實際上，對每個表你最多可以建立249個非聚簇索引。你也可以對一個表同時建立聚簇索引和非聚簇索引。（北京北大青鳥）
假如你不僅想根據日期，而且想根據用戶名從你的網點活動日志中取數據。在這種情況下，同時建立一個聚簇索引和非聚簇索引是有效的。你可以對日期時間字段建立聚簇索引，對用戶名字段建立非聚簇索引。如果你發現你需要更多的索引方式，你可以增加更多的非聚簇索引。
非聚簇索引需要大量的硬盤空間和內存。另外，雖然非聚簇索引可以提高從表中 取數據的速度，它也會降低向表中插入和更新數據的速度。每當你改變了一個建立了非聚簇索引的表中的數據時，必須同時更新索引。因此你對一個表建立非聚簇索引時要慎重考慮。如果你預計一個表需要頻繁地更新數據，那么不要對它建立太多非聚簇索引。另外，如果硬盤和內存空間有限，也應該限制使用非聚簇索引的數量。
索引屬性
這兩種類型的索引都有兩個重要屬性：你可以用兩者中任一種類型同時對多個字段建立索引（復合索引）；兩種類型的索引都可以指定為唯一索引。
你可以對多個字段建立一個復合索引，甚至是復合的聚簇索引。假如有一個表記錄了你的網點訪問者的姓和名字。如果你希望根據完整姓名從表中取數據，你需要建立一個同時對姓字段和名字字段進行的索引。這和分別對兩個字段建立單獨的索引是不同的。當你希望同時對不止一個字段進行查詢時，你應該建立一個對多個字段的索引。如果你希望對各個字段進行分別查詢，你應該對各字段建立獨立的索引。（北京北大青鳥）
兩種類型的索引都可以被指定為唯一索引。如果對一個字段建立了唯一索引，你將不能向這個字段輸入重復的值。一個標識字段會自動成為唯一值字段，但你也可以對其它類型的
字段建立唯一索引。假設你用一個表來保存你的網點的用戶密碼，你當然不希望兩個用戶有相同的密碼。通過強制一個字段成為唯一值字段，你可以防止這種情況的發生。
用SQL建立索引
為了給一個表建立索引，啟動任務欄SQL Sever 程序組中的ISQL/w 程序。進入查詢窗
口后，輸入下面的語句：
CREATE INDEX mycolumn_index ON mytable (myclumn)
這個語句建立了一個名為mycolumn_index 的索引。你可以給一個索引起任何名字，但你應該在索引名中包含所索引的字段名，這對你將來弄清楚建立該索引的意圖是有幫助的。
注意：
在本書中你執行任何SQL語句，都會收到如下的信息：
This command did not return data,and it did not return any rows
這說明該語句執行成功了。
索引mycolumn_index對表mytable 的mycolumn字段進行。這是個非聚簇索引，也是個非唯一索引。（這是一個索引的缺省屬性）如果你需要改變一個索引的類型，你必須刪除原來的索引并重建 一個。建立了一個索
引后，你可以用下面的SQL 語句刪除它：
DROP INDEX mytable.mycolumn_index
注意在DROP INDEX 語句中你要包含表的名字。在這個例子中，你刪除的索引是
mycolumn_index，它是表mytable 的索引。
要建立一個聚簇索引，可以使用關鍵字CLUSTERED。）記住一個表只能有一個聚簇索引。
（這里有一個如何對一個表建立聚簇索引的例子：（北京北大青鳥）
CREATE CLUSTERED INDEX mycolumn_clust_index ON mytable(mycolumn)
如果表中有重復的記錄，當你試圖用這個語句建立索引時，會出現錯誤。但是有重復記錄的表也可以建立索引；你只要使用關鍵字ALLOW_DUP_ROW把這一點告訴SQL Sever 即可：
CREATE CLUSTERED INDEX mycolumn_cindex ON mytable(mycolumn)
WITH ALLOW_DUP_ROW
這個語句建立了一個允許重復記錄的聚簇索引。你應該盡量避免在一個表中出現重復記錄，但是，如果已經出現了，你可以使用這種方法。
要對一個表建立唯一索引，可以使用關鍵字UNIQUE。對聚簇索引和非聚簇索引都可以使用這個關鍵字。這里有一個例子：
CREATE UNIQUE COUSTERED INDEX myclumn_cindex ON mytable(mycolumn)
這是你將經常使用的索引建立語句。無論何時，只要可以，你應該盡量對一個對一個表建立唯一聚簇索引來增強查詢操作。最后，要建立一個對多個字段的索引──復合索引──在索引建立語句中同時包含多個字段名。下面的例子對firstname 和lastname兩個字段建立索引：
CREATE INDEX name_index ON username(firstname,lastname)
這個例子對兩個字段建立了單個索引。在一個復合索引中，你最多可以對16 個字段進
行索引。
一. 聚集索引B樹分析（北京北大青鳥）
1.聚集索引按B樹結構進行組織的，索引B樹種的每一頁稱為一個索引節點。B樹的頂端節點稱為根節點。
索引中的低層節點稱為葉節點。根節點與葉節點之間的任何索引級別統稱為中間級。在聚集索引中，葉節點包含基礎表的數據頁。
根節點和中間級節點包含存有索引行的索引頁。每個索引行包含一個鍵值和一個指針，該指針指向 B 樹上的某一中間級頁或葉級索引中的某個數據行.每級索引中的頁均被連接在雙向鏈接列表中。
2.索引使用的每一個分區的index_id = 1 ，默認情況下聚集索引單個分區，當使用分區表的時候，每個分區都有一個包含該特定分區相關數據的B樹結構，我是這么理解的不知道對不對?
3.SQL Server 寫入的數據，數據鏈內的頁和行將按聚集索引鍵值進行排序。
4.SQL Server 將在索引中查找該范圍的起始鍵值，然后用向前或向后在數據頁中進行掃描。為了查找數據頁鏈的首頁，SQL Server 將從索引的根節點沿最左邊的指針進行掃描。
聚集索引B樹圖 ：
二 .優化 Transact-SQL 語句經常使用的語句 （北京北大青鳥）
1.SET STATISTICS IO {ON| OFF} /*Transact-SQL 語句生成的磁盤活動量的信息*/
2.SET SHOWPLAN_ALL ON {ON| OFF} /*返回有關語句執行情況的詳細信息，并估計語句對資源的需求*/
3.SET STATISTICS TIME {ON| OFF} /*顯示分析、編譯和執行各語句所需的毫秒數*/
4.使用T-SQL語句創建索引的語法：
CREATE [UNIQUE] [CLUSTERED|NONCLUSTERED]
INDEX index_name
ON table_name (column_name)
[WITH FILLFACTOR=x]
一. 聚集索引B樹分析
1.聚集索引按B樹結構進行組織的，索引B樹種的每一頁稱為一個索引節點。B樹的頂端節點稱為根節點。
索引中的低層節點稱為葉節點。根節點與葉節點之間的任何索引級別統稱為中間級。在聚集索引中，葉節點包含基礎表的數據頁。
根節點和中間級節點包含存有索引行的索引頁。每個索引行包含一個鍵值和一個指針，該指針指向 B 樹上的某一中間級頁或葉級索引中的某個數據行.每級索引中的頁均被連接在雙向鏈接列表中。
2.索引使用的每一個分區的index_id = 1 ，默認情況下聚集索引單個分區，當使用分區表的時候，每個分區都有一個包含該特定分區相關數據的B樹結構，我是這么理解的不知道對不對?
3.SQL Server 寫入的數據，數據鏈內的頁和行將按聚集索引鍵值進行排序。
4.SQL Server 將在索引中查找該范圍的起始鍵值，然后用向前或向后在數據頁中進行掃描。為了查找數據頁鏈的首頁，SQL Server 將從索引的根節點沿最左邊的指針進行掃描。（北京北大青鳥）
聚集索引B樹圖 ：
二 .優化 Transact-SQL 語句經常使用的語句
1.SET STATISTICS IO {ON| OFF} /*Transact-SQL 語句生成的磁盤活動量的信息*/
2.SET SHOWPLAN_ALL ON {ON| OFF} /*返回有關語句執行情況的詳細信息，并估計語句對資源的需求*/
3.SET STATISTICS TIME {ON| OFF} /*顯示分析、編譯和執行各語句所需的毫秒數*/
4.使用T-SQL語句創建索引的語法：
CREATE [UNIQUE] [CLUSTERED|NONCLUSTERED]
INDEX index_name
ON table_name (column_name)
[WITH FILLFACTOR=x]
三 創建數據測試下上面學到的理論知識（北京北大青鳥）
--創建表
CREATE TABLE employee
(
emp_username varchar (20),
emp_register DATETIME
)
--插入測試數據
DECLARE @startid INT
DECLARE @endid INT
SELECT @startid= 1,@endid = 100
WHILE @startid <=@endid
BEGIN
INSERT INTO employee (
emp_username,
emp_register
) VALUES (
/* emp_username - varchar (20) */ '劉'+CAST(@startid AS NVARCHAR(20)),
/* emp_register - DATETIME */ GETDATE() )
SELECT @startid =@startid +1;
END
-- 查詢employee的執行計劃 和 io 信息
SET STATISTICS IO ON
SELECT * FROM employee WHERE emp_username = '劉'
查看消息輸出的 IO 信息
表'employee'。(1)1掃描計數1，(2)邏輯讀取1 次，(3)物理讀取0 次，(4)預讀0 次，lob 邏輯讀取0 次，lob 物理讀取0 次，lob 預讀0 次。
輸出的信息和上面的圖片講解的是對應的
1. 執行的掃描次數 。
2. 從磁盤讀取的頁數。
3. 為進行查詢而放入緩存的頁數。
4. 預讀
T_SQL transaction 語句有很多種的寫法，但是決定那條語句是最優的是根據(logical reads) 邏輯讀取來判斷。（北京北大青鳥）
添加聚集索引 查詢邏輯讀取是否會變少
CREATE CLUSTERED INDEX Idx_emp_username ON employee (emp_username);
--然后再執行查詢
SET STATISTICS IO ON
SELECT * FROM employee WHERE emp_username = '劉'
查看消息輸出的 IO 信息
表'employee'。掃描計數1，邏輯讀取2 次，物理讀取0 次，預讀0 次，lob 邏輯讀取0 次，lob 物理讀取0 次，lob 預讀0 次。
Q 這次邏輯讀取是2次為什么呢 ?
A.難道查詢比表掃描還要慢，答案是對的，數據量小的時候，聚集索引的優勢體現不出來。
Q 為什么是2次邏輯讀取
A 現在查詢的時候如聚集索引圖，先查詢索引頁 ，查找到對應的鍵值后，掃描數據頁，如果有包含索引，直接在索引頁就可以提取到需要的數據。
上面說了小數據量的時候聚集索引體現不出效果，下面我們繼續填充數據測試 。
填充測試數據到1000
表掃描
消息：
表'employee'。掃描計數1，邏輯讀取36 次，物理讀取0 次，預讀0 次，lob 邏輯讀取0 次，lob 物理讀取0 次，lob 預讀0 次。
聚集索引掃描
消息：
表'employee'。掃描計數1，邏輯讀取2 次，物理讀取0 次，預讀0 次，lob 邏輯讀取0 次，lob 物理讀取0 次，lob 預讀0 次。
這個時候聚集索引的優勢就先顯示出來了 O(∩_∩)O
下面在來講講transaction sql 語句 ，大家在網上看到的一些人說 In like left 不使用索引 ，我們動手來測試下看他們說的對不對 ?
刪除employee表的索引
DROP INDEX employee.Idx_emp_username
打開IO信息（北京北大青鳥）
SET STATISTICS IO ON
SELECT * FROM employee WHERE employee.emp_username in ('劉10000')
消息：
表 'employee'。掃描計數 1，邏輯讀取 371 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次。
--添加Idx_emp_username聚集索引
CREATE CLUSTERED INDEX Idx_emp_username ON employee (emp_username);
SELECT * FROM employee WHERE employee.emp_username in ('劉10000');
消息:
表 'employee'。掃描計數 1，邏輯讀取 3 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次。
使用索引后邏輯讀取3次，沒有使用索引是371次，IN 很好的使用了索引!
下面我們來測試下 LIKE 是否很好的使用索引
刪除索引
DROP INDEX employee.Idx_emp_username
打開IO 信息
SET STATISTICS IO ON
執行查詢
SELECT * FROM employee WHERE employee.emp_username like ('劉1000%')
消息：
表 'employee'。掃描計數 1，邏輯讀取 371 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次。
添加索引
CREATE CLUSTERED INDEX Idx_emp_username ON employee (emp_username);
SET STATISTICS IO ON
SELECT * FROM employee WHERE employee.emp_username like ( '劉1000%');
表 'employee'。掃描計數 1，邏輯讀取 3 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次。
網上很多優化的文章寫到查詢不要使用 in like left ，其實自己動手測試下看看查詢計劃就一幕了然了（北京北大青鳥）
