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