一SqlDataRead和Dataset的選擇
Sqldataread優點讀取數據非常快如果對返回的數據不需做大量處理的情況下建議使用SqlDataReader其性能要比datset好很多缺點直到數據讀完才可close掉於數據庫的連接
(SqlDataReader 讀數據是快速向前的SqlDataReader 類提供了一種讀取從 SQL Server 數據庫檢索的只進數據流的方法它使用 SQL Server 的本機網絡數據傳輸格式從數據庫連接直接讀取數據DataReader需及時顯式的close可及時的釋放對數據的連接)
Dataset是把數據讀出緩存在內存中缺點對內存的占用較高如果對返回的數據需做大量的處理用Dataset比較好些可以減少對數據庫的連接操作優點只需連接一次就可close於數據庫的連接
*一般情況下讀取大量數據對返回數據不做大量處理用SqlDataReader對返回數據大量處理用datset比較合適對SqlDataReader和Dataset的選擇取決於程序功能的實現
二ExecuteNonQuery和ExecuteScalar
對數據的更新不需要返回結果集建議使用ExecuteNonQuery由於不返回結果集可省掉網絡數據傳輸它僅僅返回受影響的行數如果只需更新數據用ExecuteNonQuery性能的開銷比較小
ExecuteScalar它只返回結果集中第一行的第一列使用 ExecuteScalar 方法從數據庫中檢索單個值（例如id號）與使用 ExecuteReader 方法 返回的數據執行生成單個值所需的操作相比此操作需要的代碼較少
*只需更新數據用ExecuteNonQuery單個值的查詢使用ExecuteScalar數據綁定的選擇
三數據的綁定DataBinder
一般的綁定方法<%# DataBinderEval(ContainerDataItem "字段名") %>用DataBindereval 綁定不必關心數據來源(Dataread或dataset)不必關心數據的類型eval會把這個數據對象轉換為一個字符串在底層綁定做了很多工作使用了反射性能正因為使用方便了但卻影響了數據性能來看下<%# DataBinderEval(ContainerDataItem "字段名") %>當於dataset綁定時DataItem其實式一個DataRowView（如果綁定的是一個數據讀取器（dataread）它就是一個IdataRecord）因此直接轉換成DataRowView的話將會給性能帶來很大提升
<%# ctype(ContainerDataItemDataRowView)Row("字段名") %>
*對數據的綁定建議使用<%# ctype(ContainerDataItemDataRowView)Row("字段名") %>數據量大的時候可提高幾百倍的速度使用時注意方面需在頁面添加<%@ Import namespace="SystemData"%>注意字段名的大小寫（要特別注意）如果和查詢的不一致在某些情況下會導致比<%# DataBinderEval(ContainerDataItem "字段名") %>還要慢如果想進一步提高速度可采用<%# ctype(ContainerDataItemDataRowView)Row() %>的方法不過其可讀性不高
以上的是vbnet的寫法在c#中<@% ((DataRowView)ContainerDataItem)["字段名"] %>
對查看頁面每個執行過程狀態最簡單的辦法其頁面的trace屬性為true就可查看細節
一使用存儲過程
性能方面存儲過程提供了許多標准sql語言中所沒有的高級特性其傳遞參數和執行邏輯表達式的功能有助於應用程序設計者處理復雜任務另外存儲過程存儲在本地服務器上減少了執行該過程所需的網絡傳輸寬帶和執行時間（存儲過程已經對sql語句進行了預編譯所以其執行速度比在程序裡執行sql語句快很多）
程序結構方面從程序的可擴展性看使用存儲過程會對程序以後的修改帶來方便比如數據庫的結構改變了只需修改相對應的存儲結構和程序中的調用部分即可這部分不屬於本文探討范圍屬於程序結構設計方面所以不在此展開
程序安全性使用存儲過程可避免SQL Injection攻擊
二查詢語句的優化（針對sql server）
很多人只為目的寫出sql語句而不考慮sql語句的執行效率在這我只提供一優化表順序的方法（sql語句的優化和原則將會在我的sql server學習筆記中專題討論）
對sql語句執行效率可用sql server的查詢分析器來查看語句的執行過程
優化表順序一般情況下sqlserver 會對表的連接作出自動優化例如select nameno from A join B on A id=Bid join C on Cid=Aid where name=’wang’
盡管A表在From中先列出然後才是B最後才是C但sql server可能會首先使用c表它的選擇原則是相對於該查詢限制為單行或少數幾行就可以減少在其他表中查找的總數據量絕大多數情況下sql server 會作出最優的選擇但如果你發覺某個復雜的聯結查詢速度比預計的要慢就可以使用SET FORCEPLAN語句強制sql server按照表出現順序使用表如上例加上SET FORCEPLAN ON……SET FORCEPLAN OFF 表的執行順序將會按照你所寫的順序執行在查詢分析器中查看種執行效率從而選擇表的連接順序
*使用SET FORCEPLAN選擇表聯結順序
三頁面的優化（aspx）
主要針對幾個頁面屬性
EnableViewState(頁面的視圖狀態)如果無特殊要求設置為false使用ViewState 每個對象都必須先序列化到 ViewState 中然後再通過回傳進行反序列化因此使用 ViewState是沒有代價的盡量減少使用對象如果可能盡量減少放入 ViewState 中的對象的數目下面情況基本上可以禁用viewstate
（）頁面控件 （ascx）
（）頁面不回傳給自身
（）無需對控件的事件處理
（）控件沒有動態的或數據綁定的屬性值（或對於每個postpack都在代碼中處理）
單個頁面或每個頁面都禁用 ViewState如下所示單個頁面<%@ Page EnableViewState="False" %> 每個頁面在 webconfig 中 <Pages EnableViewState="false" /> EnablesessionState保持默認值即可（如果頁面用到sessionstate它才會占用資源）EnableViewStateMac如果無安全上的特殊要求保持默認值
Pagelayout頁面布局模型建議使用Flowlayout(元素不帶絕對定位屬性添加)Gridlayout(絕對定位屬性)由於采用絕對定位將會比Flowlayout生產更多的代碼主要是控件的定位信息
項目發布的時候切記解除頁面的Debug狀態
Html語言的優化我的建議是熟練掌握Html/javaScript少用vsnet自動生產的代碼它會自動生成一些無用的html代碼
smart navigation設置為true能讓用戶明顯的感覺性能提高啟用此屬性後對客戶端和服務端影響不大它能智能涮新需要涮新需涮新的部分
四控件的選擇
Html控件和服務器控件的選擇服務器控件帶來的方便和功能上的實現是html控件所不能比擬的但是是以犧牲服務器端的資源來取得的我個人建議如果html控件達不到所要實現的功能而且和一些腳本語言（如javascrpt/vbscript）結合也不能實現的話才會選擇服務器控件選擇服務器控件後也盡量對其控件優化如取消一些頁面狀態等（具體看控件的優化）
服務器控件的選擇主要針對幾個常用數據控件說明一下
DataGrid自帶最強大的數據顯示控件內置了對數據的修改刪除添加分頁等很多實用功能如果你只需對數據顯示的話盡量不要選擇DataGrid（它把數據都存儲在viewstate中）也不要使用自帶的分頁功能microsoft在自動分頁的底層做了很多工作雖然使用方便了但性能開銷大了
DataList比DataGrid功能少了很多但自定義性強了很多特有的多行數據顯示給我們帶來了很多方便DataGrid能實現的功能它基本能實現所以建議使用它
Repeater功能最少但自定義性非常強如果只需對數據顯示建議使用由於減少了很多功能對服務器的性能帶來消耗最小因此如果是對數據顯示的話我基本上都是選擇Repeater然後DataList最後DataGrid
*盡量選擇html控件能在客戶端實現的功能就在客戶端實現(熟練掌握Javascript)減少服務器的壓力數據控件選擇順序RepeaterDataListDataGrid
五服務器控件的優化
Viewstate
控件的viewstate與頁面的viewstate基本是一致的用來保存控件的一些狀態處理原則和處理頁面的viewstate一樣有興趣的可以用Datagrid綁定數據測試下viewstate保存的數據量有多大它所保存的數據基本和Datagrid顯示的數據量大小是等同的
Ispostpack
默認false需要產生事件的時候才需設置為true
控件的優化主要看你對此控件的熟悉情況對控件內部運作的原理越了解就會對其作出合適的優化
性能優化是三兩句話說不清的我所寫出的僅僅是冰山一角性能的優化是靠平時經驗的積累和對程序的運作原理的不斷認知
六異常問題
一般的問題沒有必要使用異常比如在論壇中用戶不存在用戶密碼不正確等問題因為實例化一個異常需要耗費大量的資源需要填充異常信息（異常類型拋出異常位置等）當然不是避免使用異常對於必要的異常處理還是處理的對於異常的原則是能不用就不用能用系統已有的異常的就不要生成自己的異常
From:http://tw.wingwit.com/Article/program/net/201311/14268.html
