在Oracle數據庫應用中，80%以上的性能問題源於SQL語句編寫不當。優化器雖然智能，但無法彌補根本邏輯缺陷。本文系統梳理操作符優化、寫法規範、索引利用、Hint應用四大維度，助你構建高性能SQL體系。
IN操作符雖然語法清晰，但執行流程複雜：優化器嘗試轉換為多表連接，失敗則先執行子查詢再關聯外層表。對於包含分組統計的複雜查詢，轉換往往失敗，導致性能急劇下降。
建議：高頻業務SQL優先使用EXISTS替代IN，後者僅適用於簡單靜態列表。
NOT IN無法利用索引，且對NULL值處理存在語義陷阱（子查詢含NULL導致結果為空）。
替代方案：
NOT EXISTS (SELECT 1 FROM ... WHERE ...)IS NULL判斷：SELECT * FROM A LEFT JOIN B ON A.id=B.id WHERE B.id IS NULL任何形式的不等於判斷都會放棄索引。典型重寫模式：
| 原寫法 | 優化寫法 | 適用場景 |
|---|---|---|
status != 0 | status > 0 OR status < 0 | 數值型狀態碼 |
name <> '' | name > '' | 字符串非空判斷 |
B樹索引不存儲NULL值，導致此類判斷無法走索引。
解決策略：
NOT NULL約束+默認值（如狀態字段默認'01'）col IS NOT NULL → col > ' ' OR col > 0看似同義的A > 2與A >= 3在數據分布極不均勻時差異巨大：前者需先定位=2的索引條目再過濾，後者直接定位=3。原則：優先使用等值邊界而非開區間。
-- 悪例：全表掃描
WHERE code LIKE '%5400%'
-- 優化：利用前綴索引掃描
WHERE code LIKE 'X5400%' OR code LIKE 'B5400%'
業務若需模糊匹配，考慮Oracle Text全文索引或將關鍵字段拆分為前綴列。
UNION會觸發排序去重（可能落盤），而UNION ALL僅合併結果集。除非業務確有重複且需去重，默認使用UNION ALL。典型場景：歷史表+當前表查詢，主鍵不重複時必須用UNION ALL。
以下四條語句功能相同，但產生4個不同游標：
Select * from zl_yhjbqk
Select * from dlyx.zl_yhjbqk
Select * from DLYX.ZLYHJBQK
Select * from DLYX . ZLYHJBQK -- 多空格
強制規範：統一大小寫、Schema前綴、空格風格，配合CURSOR_SHARING=FORCE/SIMILAR減少硬解析。
無索引全表掃描時，Oracle按條件順序過濾。示例：
-- 低效：先過濾99%數據
WHERE dy_dj = '1KV以下' AND xh_bz = 1
-- 高效：先過濾0.5%數據
WHERE xh_bz = 1 AND dy_dj = '1KV以下'
核心邏輯：將選擇性最高（過濾率最低）的條件前置，減少後續比較次數。
無統計信息時，Oracle按FROM順序連接。手動調整：將結果集最小的表放在最前，或確保定期執行DBMS_STATS.GATHER_TABLE_STATS讓CBO自動優化。
| 失效寫法 | 優化寫法 | 原理 |
|---|---|---|
SUBSTR(col,1,4)='5400' | col LIKE '5400%' | 函數破壞索引列順序 |
TRUNC(date_col)=TRUNC(SYSDATE) | date_col >= TRUNC(SYSDATE) AND date_col < TRUNC(SYSDATE)+1 | 範圍查詢保留索引 |
col + 20 > 50 | col > 30 | 運算移至常量側 |
'X'||col > 'X5400' | col > '5400' | 拼接破壞索引 |
col1 || col2 = 'val' | col1='val1' AND col2='val2' | 拆分為獨立條件 |
-- 字符列與數值比較，觸發TO_NUMBER隱式轉換
WHERE char_col = 5401002554 -- 錯誤
WHERE char_col = '5401002554' -- 正確
嚴格匹配數據類型，避免Oracle內部轉換導致索引失效。
ys_df > cx_df（兩業務列比較）無索引可用，需業務層面重設計（如冗餘計算列+索引）。
| 類別 | Hint示例 | 用途 |
|---|---|---|
| 目標模式 | /*+ ALL_ROWS */ /*+ FIRST_ROWS(10) */ | 吞吐量 vs 響應時間 |
| 連接方式 | /*+ USE_NL(A B) */ /*+ USE_HASH(A B) */ | 嵌套循環 vs Hash連接 |
| 索引指定 | /*+ INDEX(A idx_name) */ | 強制索引掃描 |
| 並行執行 | /*+ PARALLEL(A 4) */ | 多CPU並行查詢 |
Hint只是建議，優化器可能因成本考慮忽略它。 生產環境優先從「統計信息準確性→索引設計→SQL重寫」三個維度入手，Hint僅作最後手段。跨環境遷移時，固定Hint極易導致性能倒退。
NOT IN/!=/前導%，擁抱EXISTS/範圍查詢/UNION ALLGATHER_STATS，讓CBO決策貼近真實EXPLAIN PLAN+AUTOTRACE+實際執行時間三維驗證SQL優化無終點，唯有將原則內化為編碼習慣，才能在數據增長中保持系統穩健。
