非聚集索引結構:1:非聚集索引與聚集索引具有相同的 B 樹結構，它們之間的顯著差別在於以下兩點：
* 基礎表的數據行不按非聚集鍵的順序排序和存儲。
* 非聚集索引的葉層是由索引頁而不是由數據頁組成。
2:非聚集索引行中的行定位器或是指向行的指針，或是行的聚集索引鍵，如下所述：
* 如果表是堆（意味著該表沒有聚集索引），則行定位器是指向行的指針。該指針由文件標識符 (ID)、頁碼和頁上的行數生成。整個指針稱為行 ID (RID)。
* 如果表有聚集索引或索引視圖上有聚集索引，則行定位器是行的聚集索引鍵。如果聚集索引不是唯一的索引，SQL Server 將添加在內部生成的值（稱為唯一值）以使所有重復鍵唯一。此四字節的值對於用戶不可見。僅當需要使聚集鍵唯一以用於非聚集索引中時，才添加該值。SQL Server 通過使用存儲在非聚集索引的葉行內的聚集索引鍵搜索聚集索引來檢索數據行。
網絡觀點:order by 子句中使用了的列,可以在此列上建非聚集索引以提高查詢速度.
原文地址:http://gocom.primeton.com/blog10697_1221.htm
本人觀點:總之一句話,環境不同,表結構不同,數據分布不同,最終結果也不一定相同.
案例:本人最近做一個項目時有兩個大表關聯,都接近千萬.一個表是訂單表order,另一個是會員表member,訂單中有一字段create_date:類型為datatime,其中的值都是不相同且唯一,而且並不連續,下面是一些值:
create_date
-----------------------
2008-10-05 04:00:56.000
2008-10-05 03:55:55.000
2008-10-05 03:55:42.000
2008-10-05 03:54:40.000
2008-10-05 03:54:32.000
2008-10-05 03:54:23.000
2008-10-05 03:47:16.000
2008-10-05 03:46:08.000
2008-10-05 03:42:28.000
2008-10-05 03:42:09.000
訂單表和會員表有一個關聯字段為proxyID,各自均建有索引.查詢語句如下:
select * from order inner join member on order.proxyID=member.proxyID
where leaveDate between '開始時間' and '結束時間' order by create_date desc
測試:
情況一:在create_date上創建非聚集索引.執行的IO和所用時間消耗如下圖:可以看出這種情況對memer表進行了大量的表掃描. 83588次.
