前幾天和幾個朋友聊天,提到一些關於SQL Server方面的一些問題，褒貶不一，他們也碰到了一些性能問題，我給了一些個人的建議，也不知道是否奏效。
Q：SQL Server 2000的數據庫壓力很大，CPU和內存老不夠，但是調整的時間又有限，應該如何解決？ 從表面來看，無疑是程序問題，但是大多時候碰到這種情況是比較冤枉的
1． 程序不是自己寫的
2． 在線系統已經沒有足夠的時間去調整程序
3． 數據庫設計有些致命的問題
4． …..
不熟悉、不能和不足夠時間，我想問題大抵如此吧，簡單的建議如下1． 超過2G內存的機器，請確定是否在啟動參數中加入了 /PAE /3GB選項
2． 是否在組策略中給運行SQL Server的帳號指派了使用AWE的權限，假若沒有，查閱相關文檔啟用
3． 在SQL Server中啟用AWE，需要通過sp_configure命令來做
4． 將內存調整成固定內存，2005會好一點，如果是2000，請務必檢查啟動日志，設置太高的最小內存會有可能實效
5． 這些都做了，發現還是有問題，升級到SQL Server 2005。
這些建議都是治標不治本的，不過或許能夠幫助適當緩解數據庫的壓力，內存管理不當會讓SQL Server暈菜的。
如果還是有問題，如果還是不熟悉SQL Server，不能修改程序，更加沒有足夠的時間，那麼可以考慮做下面的一些工作1． 使用SQL Profiler，抓出執行最長的這些語句，然後看看那些where之後的字段是否建立了索引，在該建立索引的地方建立索引
2． 如果發現這個是比較復雜或者麻煩的事情，使用SQL優化向導，從某種意義上，這個小工具還是可以幫助解決問題的，聽天由命吧，能優化多少算多少
3． 如果這個也沒轍了，看看那些執行效率比較低的代碼是否是存儲過程，通過一些工具，如SQL Expert，來幫助你做一些SQL優化，然後乖乖地拷貝回去
4． 如果發現是插入語句過慢，那麼有可能是吃撐了，也就是你的索引建多了，適當看看語句的情況，該去則去吧。
如果發現還是
應用事件探查器優化SQL Server系統》，利用read80trace來幫助你分析日志吧，通過此能夠找到一些通過你剛才方法無法找到的未建立索引，蘇先生已經講述的非常詳細，我也不去COPY了。多廢話幾句：不奏效，那麼推薦去閱讀蘇有全先生的《
1． 關鍵集中在查詢時間占據最多的語句，基本上你可以理解為這是整體數據庫系統消耗的百分比
2． 另外可以適當看看I/O占有最大的語句，可能適當的磁盤系統優化也能夠幫你解決問題
因為這個問題回答的是希望能夠最簡單快速解決部分問題的情況，一些比較復雜的情況和調整就不去做了，雖然時日不長，不過一時半會應該可以撐過去。
Q：數據庫中有某個表特別大，導致查詢性能比較低，應該如何解決？ 這個問題是去參加TechED的時候路上和一個朋友討論CSDN的Blog而引發的，雖然我閱讀過部分.Text的代碼，但是了解依舊有限，只是從個人的角度給出了一些建議
1． 如果這個表包括了大量的可空字段、頻繁更新的字段（如點擊數）、大文本（文章內容），再加上這個表超過10萬條記錄，差不多剩下的日子就是等死了，
