按照本文操作和體會，會對sql優化有個基本最簡單的了解，其他深入還需要更多資料和實踐的學習：
1. 建表：
復制代碼 代碼如下:
create table site_user
(
id int IDENTITY(1,1) PRIMARY KEY,
[name] varchar(20),
code varchar(20),
date datetime
)
2. 插入8萬條數據
復制代碼 代碼如下:
declare @m int
set @m=1
while @m<80000
begin
INSERT INTO [demo].[dbo].[site_user]
(
[name]
,[code],date)
VALUES
('name'+CAST(@m AS VARCHAR(20))
,'code'+CAST(@m AS VARCHAR(20)),GETUTCDATE())
select @m=@m+1
END
--小技巧：推薦使用類似sqlassist的工具來提高敲寫sql語句的速度
3. 設置打開一些參數的設置
復制代碼 代碼如下:
SET STATISTICS IO on -- 查看磁盤IO
set statistics time on -- 查看sql語句分析編譯和執行時間
SELECT * FROM site_user -- 查看效果
4. 查看表索引情況：
sp_helpindex site_user
5. 執行sql語句
復制代碼 代碼如下:
SELECT * FROM site_user su WHERE su.name='name1'表 'site_user'。
掃描計數 1，邏輯讀取 446 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次
ctrl+L 快捷鍵查看執行計劃：
6. 優化第一步：聚集索引掃描開銷占了100%，可以考慮優化為索引查找，在查詢條件name上建立非聚集索引
復制代碼 代碼如下:
create index name_index on site_user(name)
sp_helpindex site_user -- 多出來我們新建立的索引
此時再運行上面的查詢語句：
復制代碼 代碼如下:
SELECT * FROM site_user su WHERE su.name='name1'
表 'site_user'。掃描計數 1，邏輯讀取 4 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次。
磁盤邏輯讀取次數明顯下降，然後查看執行計劃：
新建的索引已經起到了作用，但是還是去掃描了主鍵的聚集索引，如果能在一個索引上完成查詢性能會更高，因為這個查詢
所以考慮進一步優化：
7. 優化第二步： 建立組合索引
復制代碼 代碼如下:
create index name_index4 on site_user(name,code,[date])
表 'site_user'。掃描計數 1，邏輯讀取 3 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次。
-- 磁盤邏輯讀取次數又下降了
然後查看執行計劃：
這樣直接走索引查找就快很多了，使用了index4
8. 優化第三步：我們還可以考慮使用覆蓋索引，將使用到的條件都寫在索引括號內，其他查詢出來的字段放入include中，
復制代碼 代碼如下:
create index name_index5 on site_user(name)include(id,code,[date])表 'site_user'。
掃描計數 1，邏輯讀取 3 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次。
-- 磁盤邏輯讀取次數沒有明顯變化然後查看執行計劃：
同樣走索引查找使用了index5
此時： index4和index5如何選擇？
利用dbcc進行數據分析：
復制代碼 代碼如下:
DBCC SHOW_STATISTICS('site_user','name_index4')
DBCC SHOW_STATISTICS('site_user','name_index5')
可以看到，同樣的數據量，average key length：覆蓋索引index5，占用的空間相對少些，所以我們應該優先選擇覆蓋索引來進行優化
鑒於此文so easy，大家可以多多提點
作者：gaobanana
出處：http://www.cnblogs.com/gaobanana
