本文內容摘自《劍破冰山——Oracle開發藝術》一書。 1、觸發器儘量考慮內部代碼過程封裝（解析次數） 2、避免動態 SQL 動態 SQL 和普通 SQL 在執行過程中最大的差別在於：動態 SQL 是在執行過程中編譯，而普通 SQL 是在過程執行前就已經編譯過了。如果過程中有大量動態 SQL，且執行 ...
本文內容摘自《劍破冰山——Oracle開發藝術》一書。
1、觸發器儘量考慮內部代碼過程封裝（解析次數）
2、避免動態 SQL
動態 SQL 和普通 SQL 在執行過程中最大的差別在於：動態 SQL 是在執行過程中編譯，而普通 SQL 是在過程執行前就已經編譯過了。如果過程中有大量動態 SQL，且執行很頻繁，可以預計系統將會出現大量重新編譯解析的工作；而普通 SQL 在過程執行的時候已經編譯過了，就是所謂的一次編譯多次執行，效率無疑會高出許多。
3、OLTP 系統中儘量使用綁定變數，而 OLAP 不宜使用綁定變數
OLTP 系統的特點是 SQL 執行非常頻繁，並且用時非常短，此時共用池的重用執行計劃減少硬解析所省下的時間相對就非常客觀了。SQL 語句在共用池中解析是比較複雜的，將會完成邏輯優化、物理優化、生成計劃等一系列動作。大多數 OLTP 系統運用中，解析用時會占 SQL 執行總用時的很大比例，因此不容忽視。使用綁定變數後，文本內容大體一致僅變數值不同的 SQL 語句會被共用池認為是同一 SQL 語句；而未綁定變數的程式語句中有多少次迴圈就會產生多少次硬解析。
4、減少對 SYSDATE 的調用
SYSDATE 函數在開發中被大量使用，但它畢竟是函數，如果頻繁調用必然會對系統產生一定的影響，因此要有意識的避免直接調用這類函數。
5、避免對 MOD 函數的調用
MOD 函數可能是由於 Oracle 考慮了太多演算法而性能較差，自定義邏輯往往更快。
6、設法減少表掃描次數
7、避免 SQL 中的函數調用
一般而言，在 SQL 編碼中，儘量避免在 SQL 中進行函數調用，因為這樣會產生大量遞歸調用而影響性能。多數情況下 SQL 中的函數調用都是多餘的，如果用表關聯連替代函數調用，往往是更高效的。
8、儘量用簡單 SQL 替代 PL/SQL 邏輯
保持簡單是一個非常朴素的理論。在實踐中發現，寫代碼時有意識的註意到簡單兩字，將給系統性能帶來極大好處。“儘可能利用 Oracle 提供的現有功能，用最簡單的方式完成資料庫邏輯”如果可以用一條簡單 SQL 語句完成的邏輯，就避免將該 SQL 語句寫得太過複雜，只有單條 SQL 語句無法實現業務邏輯時，才考慮使用存儲過程。簡化 SQL 語句是要有充分技巧的，需要開發人員不斷加強對 Oracle 開發知識的學習和理解。（MERGE、INSERT ALL、WITH）
9、避免不必要的排序
排序是一種極耗資源的操作，在開發過程中，儘量避免不必要的排序，在不可避免的情況下，也儘可能利用索引本身有序的特性。
10、利用 Oracle 現有功能
自治事務、序列、臨時表（create global temporary table）不要費盡心思去實現 Oracle 已經提供的功能。
11、使用 PLS_INTEGER 類型
12、避免數據類型轉換
很多情況下，開發人員在代碼中由於不註意數據類型一致性，導致了系統性能低下。數據類型轉換需要額外開銷，甚至會導致無法使用索引。
13、IF 的順序有講究
14、設計開發對列是否為空慎重決定
觀察到周圍設計開發人員在進行表結構設計時，對錶欄位是否為空比較隨意，其實這在開發中是要引起重視的。
15、分散式開發不可不知的 HINT(driving_site)
本文鏈接：http://www.cnblogs.com/hanzongze/p/oracle-sql-performance.html
版權聲明：本文為博客園博主 韓宗澤 原創，作者保留署名權！歡迎通過轉載、演繹或其它傳播方式來使用本文，但必須在明顯位置給出作者署名和本文鏈接！個人博客，能力有限，若有不當之處，敬請批評指正，謝謝！
