【主題】
在某個大型網站中，有張保存新聞記錄的表，數據庫量5萬左右（其實不算大），網站頁面中的新聞都是從該表中動態生產的，同時還有80~90家的通髮網站中的新聞也是從該表中動態生產的。導致該表的訪問量非常地的大，尤其是在搞活動時網站幾乎崩潰。針對這種情況，對網站進行優化，並闡述優化中發現或可能導致死循環的情況。
【聲明】
該文已經博客園上發佈過，但在修改網友提出的問題時，出了問題。在這裏按照上篇和下篇進行發佈。dudu,若果我的行爲不妥，請刪除該文。謝謝！
【網站框架】IIS6.0+MS SQL 2000 +ASP3.0+win 2003
【思路】
1、 利用windows 任務管理器，查看進程cup佔用情況。如果數據庫進程（sqlservr.exe）佔用的cup很高的話，一般來說要在數據庫優化（這裏不談優化工具）上下功夫；如果IIS 進程（w3pw.exe）佔用的cup很高（高的有點離譜，甚至是瞬間很高）的話，就要看看代碼了，有死循環的嫌疑很大。
2、 數據庫中的優化主要從建立索引，查詢語句，存儲過程，ASP代碼等方面進行優化。
3、 IIS方面可以建立應用程序池，實現優化。
4、 本文不談服務器硬件升級。
【實戰】
1、 打開服務器的任務管理器
假設：sqlservr.exe佔用的cup非常的高，這時的服務器cup達到100%
數據庫優化攻略：
A、 先從數據庫本身着手，建立索引。建立索引這一個話題，就可以寫一篇很長的文章。
（1） 索引的結構：
可以把索引理解爲一種特殊的目錄。微軟的SQL SERVER提供了兩種索引：聚集索引（clustered index，也稱聚類索引、簇集索引）和非聚集索引（nonclustered index，也稱非聚類索引、非簇集索引）。
在 網看到一篇文章講聚類索引與非聚類索引，很通俗：我們的漢語字典的正文本身就是一個聚集索引。比如，我們要查“安”字，就會很自然地翻開字典的前幾頁，因 爲“安”的拼音是“an”，而按照拼音排序漢字的字典是以英文字母“a”開頭並以“z”結尾的，那麼“安”字就自然地排在字典的前部。如果您翻完了所有以 “a”開頭的部分仍然找不到這個字，那麼就說明您的字典中沒有這個字；同樣的，如果查“張”字，那您也會將您的字典翻到最後部分，因爲“張”的拼音是 “zhang”。也就是說，字典的正文部分本身就是一個目錄，您不需要再去查其他目錄來找到您需要找的內容。
我們把這種正文內容本身就是一種按照一定規則排列的目錄稱爲“聚集索引”。
如果您認識某個字，您可以快速地從自動中查到這個字。但您也可能會遇到您不認識的字，不知道它的發音，這時候，您就不能按照剛纔的方法找到您要查的字，而 需要去根據“偏旁部首”查到您要找的字，然後根據這個字後的頁碼直接翻到某頁來找到您要找的字。但您結合“部首目錄”和“檢字表”而查到的字的排序並不是 真正的正文的排序方法，比如您查“張”字，我們可以看到在查部首之後的檢字表中“張”的頁碼是672頁，檢字表中“張”的上面是“馳”字，但頁碼卻是63 頁，“張”的下面是“弩”字，頁面是390頁。很顯然，這些字並不是真正的分別位於“張”字的上下方，現在您看到的連續的“馳、張、弩”三字實際上就是他 們在非聚集索引中的排序，是字典正文中的字在非聚集索引中的映射。我們可以通過這種方式來找到您所需要的字，但它需要兩個過程，先找到目錄中的結果，然後 再翻到您所需要的頁碼。
我們把這種目錄純粹是目錄，正文純粹是正文的排序方式稱爲“非聚集索引”。
（2）聚類與非聚類索引使用的一般規則：
|
動作描述 |
使用聚集索引 |
使用非聚集索引 |
|
列經常被分組排序 |
應 |
應 |
|
返回某範圍內的數據 |
應 |
不應 |
|
一個或極少不同值 |
不應 |
不應 |
|
小數目的不同值 |
應 |
不應 |
|
大數目的不同值 |
不應 |
應 |
|
頻繁更新的列 |
不應 |
應 |
|
外鍵列 |
應 |
應 |
|
主鍵列 |
應 |
應 |
|
頻繁修改索引列 |
不應 |
應 |
（3）根據實際情況，不要認爲主鍵應該使用聚類索引（MS SQL 把主鍵設爲默認的聚類索引）。通常，我們會在每個表中都建立一個ID列，以區分每條數據，並且這個ID列是自動增大的，步長一般爲1。此時，如果我們將這 個列設爲主鍵，SQL SERVER會將此列默認爲聚集索引。這樣做可以讓您的數據在數據庫中按照ID進行物理排序，但在實際應用中，因爲ID號是自動生成的，我們並不知道每條 記錄的ID號，所以我們很難在實踐中用ID號來進行查詢。這就使讓ID號這個主鍵作爲聚集索引成爲一種資源浪費。
（4）SQL語句優化的實例：
SARG的定義：用於限制搜索的一個操作，因爲它通常是指一個特定的匹配，一個值得範圍內的匹配或者兩個以上條件的AND連接。形式如下：
列名 操作符 <常數 或 變量>或<常數 或 變量> 操作符列名
1)、如果在表中的name自段上建立索引，在用like進行模糊查詢
請使用name like '張%'
不用使用：name like '%張%'
字符串的開始使用配符%，索引將無法使用。
2）、or語句的代價是引起全表掃描
Name='張三' and age > 20
Name='張三' or age > 20
第二條語句將引起全表的掃描。請注意使用，儘量避免。
3）、不用寫select * from table 這樣的語句
如果只需名稱和年齡，要養成使用select name ,age from table的習慣。
4）、請謹慎地使用嵌套查詢
對於 select name from table where age in (select age from table)之類的語句，將引起全表的掃描，索引也就沒有意義了。
5）、在實現記錄分頁時，請利用top
實現分頁的經典語句：
SELECT TOP PAGESIZE NEWSTITLE
FORM NEWSINFO WHERE NEWSID NOT IN
(SELECT TOP (PAGE-1)* PAGESIZE NEWSID FROM NEWSINFO
WHERE Auditing=1 and NEWSBREED='企業新聞' order by NEWSID DESC)
AND Auditing=1 and NEWSBREED='企業新聞' order by NEWSID DESC
其中：PAGE表示當前頁數，PAGESIZE表示頁的大小；這裏利用了NOT IN,但總比一次讀取全部的記錄要好。
針對本人的實例還有一個更好的方案：因爲NEWSID字段是自增字段，對於NOT IN 進行如下的改造，比不影響結果。但速度提高了很多
SELECT TOP PAGESIZE NEWSTITLE
FORM NEWSINFO WHERE NEWSID >
(SELECT MAX(NEWSID) FROM (SELECT TOP (PAGE-1) * PAGESIZE NEWSID FROM NEWSINFO WHERE Auditing=1 and NEWSBREED='企業新聞' order by NEWSID ) AS TB)AND Auditing=1 and NEWSBREED='企業新聞' order by NEWSID
6）、複合索引的前導列，是最經常在查詢條件中使用的
比如在 PUTDT,AUTHORNAME列上建立了複合的索引，其中PUTDT爲前導列
對於如下的三條語句：
SELECT PUTDT, AGE FROM USER_NEWS WHERE PUTDT > '2007-1-16'
SELECT PUTDT, AGE FROM USER_NEWS WHERE PUTDT>'2007-1-16'and AUTHORNAME='DAVID'
SELECT PUTDT, AGE FROM USER_NEWS WHERE AUTHORNAME='DAVID'
說明：
第一條語句速度最快，其次爲第二條，第三條最慢。
第三條中索引是無效的。所以建立複合索引，要注意細節。
第二條中條件語句的順序不影響性能，"查詢優化器"來做優化工作
7）、如果COUTN（*）只用於獲取行數，可以使用ROWSET COUNT 。
8）、檢查SQL 語句性能的方法
A、打開"查詢分析器"，打開"查詢"菜單，點擊"顯示查詢計劃"，執行下面的語句
select title,price from titles where title_id in
(select title_id from sales where qty>30)
select title,price from titles where exists
(select * from sales where sales.title_id=titles.title_id and qty>30)
查看查詢計劃：
從套紅的部分看，這兩條語句性能是一樣的，也驗證了IN 和 EXISTS是等效的。
Ｂ、在各個select語句前加：declare @d datetime set @d=getdate() 並在select語句後加：select [語句執行花費時間(毫秒)]=datediff(ms,@d,getdate())
可以知道SQL語句執行需要的毫秒數。
B、採用了以上的優化以後，發現數據庫的進程佔用的cup有所下降，但還是偏高。
請使用ＭＳ SQＬ事件探查器，跟蹤MS ＳＱＬ的請求
打開“事件探查器”，新建“跟蹤"
1）、如果“事件探查器”中，有很多的RPC事件，並且執行sp_cursoropen sp_cursorfetch
Sp_cursorclose ,說明在使用ASP數據集對象時，使用的遊標服務不合適。
請使用“客戶端遊標”，代碼：RS.CursorLocation=3 其中RS爲數據集對象，3表示客戶端遊標，不要使用adUseClient，有時會有問題。
2）、數據集對象的操作要注意的地方
RS.Open一般建議：
rs.open sql,conn,0,1 順序遍歷，不需要定位跳轉，不需要添加刪除更新操作，速度最快
rs.open sql,conn,1,3 遍歷，可以進行更新操作，但不能進行定位跳轉
rs.open sql,conn,2,3 可以進行所有操作，可以跳轉
說明：第三個參數表示遊標的類型，第四個參數表示鎖類型
可以參考：http://www.cnblogs.com/David-weihw/archive/2007/01/10/616936.html
經過以上的優化，一般應該可以解決MS SQL進程佔用cup過高的情況。如果還不行的話，就嚴重了，請重新設計數據庫存儲結構去吧。