將不進行維護，轉站到我的個人博文：
位址os：這裡對聚集所以和非聚集所以的概念說明就不敘述了。
身為程式猿，在平時的開發中，資料的操作是經常要做的事情，大多數公司是沒有dba的，程式開發人員的在運算元據的時候根本不會去看sql語句執行的效率，所以就時常的遇到大資料的情況下查詢資料庫總會遇到各種緩慢loading的情況。
從使用者的角度來說，我褲子都脫了，你給我看這個？
從技術的角度來說，我他麼這麼流弊，怎麼可以讓查詢這麼卡。
因此，作為程式猿的我們，在沒有dba的情況下，要掌握最基本的加快資料庫查詢的意識和技能；
直接上例項，動態說明，有圖有真相，簡單粗暴。
這裡我們先建立一張表：
create table [dbo].[student]([id] [int] identity(1,1) not null,
[name] [nvarchar](50) not null,
[age] [int] not null,
[height] [int] not null,
[address] [nvarchar](100) null,
[class] [nvarchar](50) not null,
[entrancedatetime] [datetime] not null,
constraint [pk_student] primary key clustered
([id] asc
)with (pad_index = off, statistics_norecompute = off, ignore_dup_key = off, allow_row_locks = on, allow_page_locks = on) on [primary]
) on [primary]
go
alter table [dbo].[student] add constraint [df_student_entrancedatetime] default (getdate()) for [entrancedatetime]往表裡插入 500萬資料：go
declare @i int;1.合理的使用索引提高查詢速度set @i=1;
while(@i<5000001)begin
insert into dbo.student(name,age,height,[address],class,entrancedatetime)
values('yang_'+convert(nvarchar(10),@i),rand()*10+7,rand()*100+50,'廈門土豪小區1座'+convert(nvarchar(10),convert(int,rand()*100+1))+'號',convert(nvarchar(10),convert(int,rand()*6+1))+'年級',getdate())
set @i=@i+1;
end
查詢表裡，所有年齡為10的名字，如圖：
從圖中可以看出，使用了聚集索引掃瞄，邏輯讀取55057次
新增索引：
很明顯的看出來，查詢優化器使用了索引查詢，邏輯讀取次數變少為：2411，很可觀。
(在執行計畫中看到索引查詢，就是說明索引被使用到了，如果出現索引掃瞄就說明索引沒有被使用到)
這裡注意：
誤區：我新增了索引查詢速度就一定比
表掃瞄來得快，並且索引一定會被使用
我的總結理解：一，索引不一定比掃瞄快，在資料量少的情況下，使用表掃瞄會比索引來得快，二，新增了索引不一定會被使用，首先要知道sqlserver在執行語句的時候會選擇最優耗能少的方案去執行，在索引無法達到最高效的情況下，就不會被使用到。
比如：下面的查詢操作，就沒有使用到索引了，而是使用到了聚集索引掃瞄
出現上面的情況是為什麼呢？
因為我建立的索引裡，只有覆蓋了name欄位，現在我查詢的是address欄位，不在索引的覆蓋中，那麼查詢優化器在執行語句的時候就沒有使用到了索引，選擇了開銷更小的聚集索引掃瞄
但是我就是這麼任性，要強制要求使用索引來查詢，結果如截圖：
這個結果就很明顯了，邏輯讀次數，和掃瞄次數多了很多。計畫裡也給了提示，讓我們索引覆蓋address欄位
2.合理的使用聚集索引
我們在新增表的主鍵的時候就會預設的將主鍵新增為聚集索引，但是並不是聚集索引就一定要是主鍵字段，一張表就只能新增乙個聚集索引，所以合理的利用聚集索引的特性，可以很大的提高查詢速度。
這個時候就可以將聚集索引加到時間欄位裡，你會發現整個查詢就會高效很多。
3，4，5，6
未完待續。。。
-----------------------------------[我只是美麗的分割線]-----------------------------------------
索引的優缺點
優點： 加快訪問速度, 加強行的唯一性
建立索引的指導原則
請按照下列標準選擇建立索引的列：
該列用於頻繁搜尋
該列用於對資料進行排序
請不要使用下面的列建立索引：
列中僅包含幾個不同的值。
表中僅包含幾行。為小型表建立索引可能不太划算，因為sql server在索引中搜尋資料所花的時間比在表中逐行搜尋所花的時間更長
假設我們在col1列上建立了單列索引，可以在以下謂詞上進行索引查詢：
ø [col1] = 3.14然而，在以下謂詞上將不能使用索引查詢：ø [col1] > 100
ø [col1] between 0 and 99
ø [col1] like 'abc%'
ø [col1] in (2, 3, 5, 7)
ø abs([col1]) = 1-----------------------------------[我只是美麗的分割線]-----------------------------------------ø [col1] + 1 = 9
ø [col1] like '%abc'
聚集索引和非聚集索引的區別
暫且摘錄如下 摘錄1 前者加在不常更新的表，後者加在經常更新的表 摘錄2 使用聚集索引 聚集索引確定表中資料的物理順序。聚集索引類似於 簿，後者按姓氏排列資料。由於聚集索引規定資料在表中的物理儲存順序，因此乙個表只能包含乙個聚集索引。但該索引可以包含多個列 組合索引 就像 簿按姓氏和名字進行組織一樣...
聚集索引和非聚集索引的特點
索引分類 按照維護與管理索引角度分為 唯一索引 復合索引和系統自動建立的索引 按照儲存方式分為 聚集與非聚集索引 1 聚集索引 表中儲存的資料按照索引的順序儲存，檢索效率比普通索引高，索引占用硬碟 儲存空間小 1 左右 但對資料新增 修改 刪除的速度影響比較大 降低 特點 1 無索引，資料無序 2 ...
聚集索引和非聚集索引的區別
聚集索引和非聚集索引的區別 漢語字典的正文本身就是乙個聚集索引。比如，我們要查 安 字，就會很自然地翻開字典的前幾頁，因為 安 的拼音是 an 而按照拼音排序漢字的字典是以英文本母 a 開頭並以 z 結尾的，那麼 安 字就自然地排在字典的前部。如果您翻完了所有以 a 開頭的部分仍然找不到這個字，那麼...