您好,登錄后才能下訂單哦!
1、開發人員如果用到其他庫的Table或View,務必在當前庫中建立View來實現跨庫操作,最好不要直接使用“databsevv.dbo.table_name”,因為sp_depends不能顯示出該SP所使用的跨庫table或view,不方便校驗。
2、開發人員在提交SP前,必須已經使用set showplan on分析過查詢計劃,做過自身的查詢優化檢查。
3、高程序運行效率,優化應用程序,在SP編寫過程中應該注意以下幾點:
a) 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. 注意Oracle存儲過程中參數和數據類型的關系。
xi. 注意insert、update操作的數據量,防止與其他應用沖突。如果數據量超過200個數據頁面(400k),那么系統將會進行鎖升級,頁級鎖會升級成表級鎖。
b) 索引的使用規范:
i. 索引的創建要與應用結合考慮,建議大的OLTP表不要超過6個索引。
ii. 盡可能的使用索引字段作為查詢條件,尤其是聚簇索引,必要時可以通過index index_name來強制指定索引
iii. 避免對大表查詢時進行table scan,必要時考慮新建索引。
iv. 在使用索引字段作為條件時,如果該索引是聯合索引,那么必須使用到該索引中的第一個字段作為條件時才能保證系統使用該索引,否則該索引將不會被使用。
v. 要注意索引的維護,周期性重建索引,重新編譯Oracle存儲過程。
c) tempdb的使用規范:
i. 盡量避免使用distinct、orderby、groupby、having、join、***pute,因為這些語句會加重tempdb的負擔。
ii. 避免頻繁創建和刪除臨時表,減少系統表資源的消耗。
iii. 在新建臨時表時,如果一次性插入數據量很大,那么可以使用select into代替create table,避免log,提高速度;如果數據量不大,為了緩和系統表的資源,建議先create table,然后insert。
iv. 如果臨時表的數據量較大,需要建立索引,那么應該將創建臨時表和建立索引的過程放在單獨一個子存儲過程中,這樣才能保證系統能夠很好的使用到該臨時表的索引。
v. 如果使用到了臨時表,在存儲過程的最后務必將所有的臨時表顯式刪除,先truncate table,然后drop table,這樣可以避免系統表的較長時間鎖定。
vi. 慎用大的臨時表與其他大表的連接查詢和修改,減低系統表負擔,因為這種操作會在一條語句中多次使用tempdb的系統表。
d) 合理的算法使用:
根據上面已提到的SQL優化技術和ASE Tuning手冊中的SQL優化內容,結合實際應用,采用多種算法進行比較,以獲得消耗資源最少、效率最高的方法。具體可用ASE調優命令:setstatistics io on, setstatisticstimeon , set showplan on等。
Oracle中Oracle存儲過程和Sql語句的優化重點2008-07-2909:14 | 末日風情
1.全表掃描和索引掃描
大數據量表盡量要避免全表掃描,全部掃描會按順序每條記錄掃描,對于>100萬數據表影響很大。
Oracle中通過RowID訪問數據是最快的方式
對字段進行函數轉換,或者前模糊查詢都會導致無法應用索引而進行全表掃描
對Oracle共享池和緩沖區中的Sql必須要大小寫都完全用上才能夠匹配上
2.順序問題
Oracle按照從右到左的順序對數據表進行解析。因此From最后面的表為基礎表,一般要選擇記錄數最少的表作為基礎表。
對于Where條件的順序,過濾到最大查詢記錄數量的條件必須寫在Where條件的結尾處。
Where條件中涉及到使用復雜函數判定的必須注意要寫到Where條件的最前面
3.索引方面
記錄數少的表保留有主鍵索引就可以了,不要再去建其它索引,全表掃描也很快
索引最好單獨建立表空間,必要時候對索引進行重建
必要時候可以使用函數索引,但不推薦使用
Oracle中的視圖也可以增加索引,但一般不推薦使用
*Sql語句中大量使用函數時候會導致很多索引無法使用上,要針對具體問題分析
4.其它
避免使用Select *,因為系統需要去幫你將*轉換為所有的列名,這個需要額外去查詢數據字典。
Count(1)和Count(*)差別不大。
多使用Decode函數來作簡單的代碼和名稱間的轉換,以減少表關聯
使用Truncate替代delete來刪除記錄,但Truncate數據不記錄日志,無法進行回滾
對于復雜的Oracle存儲過程可以多次提交的數據的要多分多次Commit,否則長事務對系統性能影響很大
Distinct和Having子句都是耗時操作,應該盡可能少使用
在不需要考慮重復記錄合并時候用Union All來代替Union
使用顯性游標而不使用隱性游標,特別是大數據量情況下隱性游標對性能影響很大
是否使用函數的問題
用直接的表關聯來代替Exist.用Exist或Not Exists來代理In。In進行子查詢效率很差。
5.SQL語句分析
通過SQLPLUS中的SET TRACE功能對Sql語句的性能進行分析
通過Toad或PL/SQL Developer對語句的性能進行和索引的使用情況進行分析
對Oracle缺省的優化不滿意可以強制使用Hint,但一般不推薦使用
對Flag等只存儲是或否信息的字段,一般不推薦建立索引。必要可以采用位圖索引
*存在遞歸查詢情況如果關聯Table太多對性能會造成較大影響,往往推薦采用臨時表轉為分步驟操作提高性能
*盡量使用表關聯查詢而不使用函數,但涉及類似于代碼表要重復關聯多次取數據問題時候又適合使用函數
上述的相關內容就是對Oracle存儲過程編寫經驗和優化措施的描述,希望會給你帶來一些幫助在此方面。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。