SQL 陳述式最佳化原則:
1． IN 操作符
用IN寫出來的SQL的優點是比較容易寫及清晰易懂，這比較適合現代軟體開發的風格。
但是用IN的SQL效能總是比較低的，從執行的步驟來分析用IN的SQL與不用IN的SQL有以下區別：
將其轉換成多個表的串連，如果轉換不成功則先執行IN裡面的子查詢，再查詢外層的表記錄，如果轉換成功則直接採用多個表的串連方式查詢。由此可見用IN的SQL至少多了一個轉換的過程。一般的SQL都可以轉換成功，但對於含有分組統計等方面的SQL就不能轉換了。
推薦方案：在業務密集的SQL當中盡量不採用IN操作符。可以用exists代替。
SQL Server例子：
Exists用法：
select * from kj_dept where exists (select * from kj_dept_info where kj_dept.dept_id = dept_id and dept_id=XXX)
in用法：
select * from kj_dept where dept_id in (select dept_id from kj_dept_info where dept_id=XXX)
2．NOT IN操作符
此操作是強列推薦不使用的，因為它不能應用表的索引。
推薦方案：用NOT EXISTS 或（外串連+判斷為空白）方案代替。 3. <> 操作符（不等於）
不等於操作符是永遠不會用到索引的，因此對它的處理只會產生全表掃描。
推薦方案：用其它相同功能的操作運算代替，如
a<>0 改為 a>0 or a<0
a<>’’ 改為 a>’’ 4．IS NULL 或IS NOT NULL操作（判斷欄位是否為空白）
判斷欄位是否為空白一般是不會應用索引的，因為B樹索引是不索引空值的。
推薦方案：用其它相同功能的操作運算代替，如
a is not null 改為 a>0 或a>’’等。
不允許欄位為空白，而用一個預設值代替空值，如業擴申請中狀態欄位不允許為空白，預設為申請。 5． > 及 < 操作符（大於或小於操作符）
大於或小於操作符一般情況下是不用調整的，因為它有索引就會採用索引尋找，但有的情況下可以對它進行最佳化，如一個表有100萬記錄，一個數值型欄位A，30萬記錄的A=0，30萬記錄的A=1，39萬記錄的A=2，1萬記錄的A=3。那麼執行A>2與A>=3的效果就有很大的區別了，因為A>2時ORACLE會先找出為2的記錄索引再進行比較，而A>=3時ORACLE則直接找到=3的記錄索引。
6．LIKE操作符
LIKE操作符可以應用萬用字元查詢，裡面的萬用字元組合可能達到幾乎是任意的查詢，但是如果用得不好則會產生效能上的問題，如LIKE ‘%5400%’ 這種查詢不會引用索引，而LIKE ‘X5400%’則會引用範圍索引。一個實際例子：用YW_YHJBQK表中營業編號後面的戶標識號可來查詢營業編號 YY_BH LIKE ‘%5400%’ 這個條件會產生全表掃描，如果改成YY_BH LIKE ’X5400%’ OR YY_BH LIKE ’B5400%’ 則會利用YY_BH的索引進行兩個範圍的查詢，效能肯定大大提高。 7. UNION操作符
UNION在進行錶鏈接後會篩選掉重複的記錄，所以在錶鏈接後會對所產生的結果集進行排序運算，重複資料刪除的記錄再返回結果。實際大部分應用中是不會產生重複的記錄，最常見的是過程表與曆史表UNION。如：
select * from gc_dfys
union
select * from ls_jg_dfys
這個SQL在運行時先取出兩個表的結果，再用排序空間進行排序重複資料刪除的記錄，最後返回結果集，如果表資料量大的話可能會導致用磁碟進行排序。 推薦方案：採用UNION ALL操作符替代UNION，因為UNION ALL操作只是簡單的將兩個結果合并後就返回。
select * from gc_dfys
union all
select * from ls_jg_dfys 8. WHERE後面的條件順序影響
WHERE子句後面的條件順序對大資料量表的查詢會產生直接的影響，如：
Select * from zl_yhjbqk where dy_dj = '1KV以下' and xh_bz=1
Select * from zl_yhjbqk where xh_bz=1 and dy_dj = '1KV以下'
以上兩個SQL中dy_dj（電壓等級）及xh_bz（銷戶標誌）兩個欄位都沒進行索引，所以執行的時候都是全表掃描；第一條SQL的dy_dj = '1KV以下'條件在記錄集內比率為99%，而xh_bz=1的比率只為0.5%，在進行第一條SQL的時候99%條記錄都進行dy_dj及xh_bz的比較，而在進行第二條SQL的時候0.5%條記錄都進行dy_dj及xh_bz的比較，以此可以得出第二條SQL的CPU佔用率明顯比第一條低。
表之間的串連必須寫在其他WHERE條件之前, 那些可以過濾掉最大數量記錄的條件必須寫在WHERE子句的末尾. [越有效地縮小範圍的條件越放後] 9. 查詢表順序的影響
在FROM後面的表中的列表順序會對SQL執行效能影響，在沒有索引情況下，會按表出現的順序進行連結，由此因為表的順序不對,會產生十分耗伺服器資源的資料交叉。 10. 聯結列
對於有聯結的列，即使最後的聯結值為一個靜態值，最佳化器是不會使用索引的。我們一起來看一個例子，假定有一個職工表（employee），對於一個職工的姓和名分成兩列存放（FIRST_NAME和LAST_NAME），現在要查詢一個叫比爾.克林頓（Bill Cliton）的職工。
下面是一個採用聯結查詢的SQL語句：
select * from employss
where first_name='' and last_name ='Beill Cliton';
上面這條語句完全可以查詢出是否有Bill Cliton這個員工，但是這裡需要注意，對於last_name建立的索引沒有使用。 當採用下面這種SQL語句的編寫，系統就可以採用基於last_name建立的索引。
Select * from employee where first_name ='Beill' and last_name ='Cliton';
遇到下面這種情況又如何處理呢？如果一個變數（name）中存放著Bill Cliton這個員工的姓名，對於這種情況我們又如何避免全程遍曆，使用索引呢？可以使用一個函數，將變數name中的姓和名分開就可以了，但是有一點需要注意，這個函數是不能作用在索引列上。下面是SQL查詢指令碼：
select * from employee
where
first_name = SUBSTR('&&name',1,INSTR('&&name',' ')-1)
and
last_name = SUBSTR('&&name',INSTR('&&name’,' ')+1) 11. Order by語句
ORDER BY語句決定了如何將返回的查詢結果排序。Order by語句對要排序的列沒有什麼特別的限制，也可以將函數加入列中（象聯結或者附加等）。任何在Order by語句的非索引項目或者有計算運算式都將降低查詢速度。
仔細檢查order by語句以找出非索引項目或者運算式，它們會降低效能。解決這個問題的辦法就是重寫order by語句以使用索引，也可以為所使用的列建立另外一個索引，同時應絕對避免在order by子句中使用運算式。
可以使用where子句代替order by。 12. 避免使用 ‘ * ‘
SELECT子句中避免使用 ‘ * ‘ 當你想在SELECT子句中列出所有的COLUMN時,使用動態SQL列引用 ‘*' 是一個方便的方法.不幸的是,這是一個非常低效的方法. 實際上,在解析的過程中, 會將'*' 依次轉換成所有的列名, 這個工作是通過查詢資料字典完成的, 這意味著將耗費更多的時間。 13. 用表串連替換EXISTS
通常來說採用表串連的方式比EXISTS更有效率。 14. 用EXISTS替換DISTINCT
當提交一個包含一對多表資訊(比如部門表和僱員表)的查詢時,避免在SELECT子句中使用DISTINCT. 一般可以考慮用EXIST替換。 15. 避免不合理的索引設計
合理索引設計，可以盡量使每個SQL都可以利用索引。in、or子句常會使用工作表，使索引失效；如果不產生大量重複值，可以考慮把子句拆開；拆開的子句中應該包含索引。
避免在索引列上使用NOT。 16. 通過內建函式提高SQL效率
複雜的SQL往往犧牲了執行效率，能夠掌握運用內建函式解決問題的方法，在實際工作中是非常有意義的。如果有可能，可以使用預存程序來加以實現！
但是避免在索引列上使用函數。 |
