深刻了解存儲過程的編寫經驗和優化措施

 在數據庫的開發過程當中，常常會遇到複雜的業務邏輯和對數據庫的操做，這個時候就會用SP來封裝數據庫操做。若是項目的SP較多，書寫又沒有必定的規範，將會影響之後的 系統 維護困難和大SP邏輯的難以理解，另外若是數據庫的數據量大或者項目對SP的性能要求很，就會遇到優化的問題，不然速度有可能很慢，通過親身經驗，一個通過優化過的SP要比一個性能差的SP的效率甚至高几百倍。

　　一、開發人員若是用到其餘庫的Table或View，務必在當前庫中創建View來實現跨庫操做，最好不要直接使用「databse.dbo.table_name」，由於sp_depends不能顯示出該SP所使用的跨庫table或view，不方便校驗。

　　二、開發人員在提交SP前，必須已經使用set showplan on分析過查詢計劃，作過自身的查詢優化檢查。

　　三、高程序運行效率，優化應用程序，在SP編寫過程當中應該注意如下幾點：

　　SQL的使用規範

　　i. 儘可能避免大事務操做，慎用holdlock子句，提升系統併發能力。

　　ii. 儘可能避免反覆訪問同一張或幾張表，尤爲是數據量較大的表，能夠考慮先根據條件提取數據到臨時表中，而後再作鏈接。

　　iii.儘可能避免使用遊標，由於遊標的效率較差，若是遊標操做的數據超過1萬行，那麼就應該改寫；若是使用了遊標，就要儘可能避免在遊標循環中再進行錶鏈接的操做。

　　iv. 注意where字句寫法，必須考慮語句順序，應該根據索引順序、範圍大小來肯定條件子句的先後順序，儘量的讓字段順序與索引順序相一致，範圍從大到小。

　　v. 不要在where子句中的「=」左邊進行函數、算術運算或其餘表達式運算，不然系統將可能沒法正確使用索引。

　　vi. 儘可能使用exists代替select count(1)來判斷是否存在記錄，count函數只有在統計表中全部行數時使用，並且count(1)比count(*)更有效率。

　　vii.儘可能使用「>=」，不要使用「>」。

　　viii.注意一些or子句和union子句之間的替換

　　ix.注意表之間鏈接的數據類型，避免不一樣類型數據之間的鏈接。

　　x. 注意存儲過程當中參數和數據類型的關係。

　　xi.注意insert、update操做的數據量，防止與其餘應用衝突。若是數據量超過200個數據頁面（400k），那麼系統將會進行鎖升級，頁級鎖會升級成表級鎖。

　　索引的使用規範

　　i. 索引的建立要與應用結合考慮，建議大的OLTP表不要超過6個索引。

　　ii. 儘量的使用索引字段做爲查詢條件，尤爲是聚簇索引，必要時能夠經過index index_name來強制指定索引

　　iii.避免對大表查詢時進行table scan，必要時考慮新建索引。

　　iv. 在使用索引字段做爲條件時，若是該索引是聯合索引，那麼必須使用到該索引中的第一個字段做爲條件時才能保證系統使用該索引，不然該索引將不會被使用。

　　v. 要注意索引的維護，週期性重建索引，從新編譯存儲過程。

　　tempdb的使用規範

　　i. 儘可能避免使用distinct、order by、group by、having、join、cumpute，由於這些語句會加劇tempdb的負擔。

　　ii. 避免頻繁建立和刪除臨時表，減小系統表資源的消耗。

　　iii.在新建臨時表時，若是一次性插入數據量很大，那麼可使用select into代替create table，避免log，提升速度；若是數據量不大，爲了緩和系統表的資源，建議先create table，而後insert。

　　iv. 若是臨時表的數據量較大，須要創建索引，那麼應該將建立臨時表和創建索引的過程放在單獨一個子存儲過程當中，這樣才能保證系統可以很好的使用到該臨時表的索引。

　　v. 若是使用到了臨時表，在存儲過程的最後務必將全部的臨時表顯式刪除，先truncate table，而後drop table，這樣能夠避免 系統 表的較長時間鎖定。

　　vi. 慎用大的臨時表與其餘大表的鏈接查詢和修改，減低系統表負擔，由於這種操做會在一條語句中屢次使用tempdb的系統表。

　　合理的算法使用

　　根據上面已提到的SQL優化技術和ASE Tuning手冊中的SQL優化內容,結合實際應用,採用多種算法進行比較,以得到消耗資源最少、效率最高的方法。具體可用ASE調優命令：set statistics io on, set statistics time on , set showplan on 等。