將絕大部分的SQL查詢改為存儲過程，這樣的操作毫無疑問可以提高部分性能。 凡是使用“select * from xxx”的操作一律具體到所需字段。 使用join連接2個以上大量數據的表，且基礎數據表變化不大的查詢一律使用視圖，并為此視圖建立索引。理由來自SQL Server聯機幫助手冊： “對于標準視圖而言，為每個引用視圖的查詢動態生成結果集的開銷很大，特別是對于那些涉及對大量行進行復雜處理（如聚合大量數據或聯接許多行）的視圖。如果在查詢中頻繁地引用這類視圖，可通過對視圖創建唯一聚集索引來提高性能。對視圖創建唯一聚集索引后，結果集將存儲在數據庫中，就像帶有聚集索引的表一樣。 對視圖創建索引的另一個好處是：優化器可以在未直接在 FROM 子句中指定某一視圖的查詢中使用該視圖的索引。這樣一來，可從索引視圖檢索數據而無需重新編碼，由此帶來的高效率也使現有查詢獲益?！? 凡是使用 "select count(*) from xxx" 或是"select count(id) from xxx”（此處id為主鍵）的查詢，一律改為”select count(1) from xxx”，理論上采用*來做聚合值，SQL Server會自動尋覓最合適的字段以進行聚合，但這樣仍然會占用系統開銷，即使主鍵也沒有1來得快。 對于多條件的組合查詢，我們一般會寫成”where ((@condition is null) or (condition=@condition))”形式的存儲過程條件來進行查詢，但這樣的操作會因為”is null ”導致性能問題，反復實地檢測后采用了”where 1 = 1 ”，然后根據條件“IF @condition IS NOT NULL SET @sqlText=@sqlText+' AND Condition=''' + @Condition +''''，最后 “exec sp_executesql @sqlText” 的方式，這樣確實可帶來明顯的性能提升，分析應是”is null ”或”is not null”導致了索引失效，進行了全表掃描。 對使用row_number()函數的表建立合適的索引，必須要有最合適的索引才能避免重建索引時的全表row_number()運算帶來的性能問題，而且索引的方向也很重要，比如時間類的索引用降序往往比升序性能高。 這個不是性能問題，但也很重要，在存儲過程中應使用scope_identity()函數來獲得最新的標量，而不是@@Identity這個全局變量，因為@@Identity會受到觸發器的影響而失去正確值。
