寫出可維護、高性能、無坑 SQL 的工程化指南
SQL 質量直接決定系統穩定性。本文提煉 10 條開發鐵律，覆蓋需求澄清、復用、簡化、NULL 處理、類型安全、去重、適度優化、綁定變量、版本控制、測試驗證，助您從「能跑」進化為「好用」。
一、記錄詳細需求文檔
- SQL 編寫前必須明確：取什麼數據、什麼約束條件。
- 數倉環境補充：對應報表、基礎表血緣。
- 開發環境補充：服務業務頁面、調用頻率、SLA。
二、不要重複造輪子
- 優先檢索現有成熟方案、模板 SQL、公共視圖/包。
- 遵循 DRY 原則，減少重複邏輯與維護面。
三、降低語句復雜度
- 拒絕炫技：過度使用分析函數、XML/JSON 處理、遞歸 CTE 等，除非帶來明顯性能/功能收益。
- 複雜 SQL 拆解為多步驟（CTE、臨時表、PL/SQL 流程），提升可讀性與可調試性。
四、小心處理 NULL
NULL ≠ 任何值（包括 NULL 自身），是 Bug 溫床：
WHERE col = xxx 不會匹配 NULL 行，需 col IS NULL。- PL/SQL 中
var := var + xxx 若 var 為 NULL，結果永遠為 NULL，需 NVL(var,0)。
五、自行核對數據類型
- WHERE 條件隱式轉換導致索引失效（如
WHERE num_col = '123'）。
- 顯式轉換：
TO_NUMBER、TO_DATE、CAST，確保類型一致。
六、小心處理重複數據
- 不關心去重或確知無重複時，優先用 UNION ALL，避免
UNION 昂貴排序/去重。
- 需去重時明確使用
DISTINCT 或 UNION，並評估性能影響。
七、避免不必要的優化操作
- 一次性查詢、報表導出、低頻任務：1s vs 2s 無業務差異，優化 ROI 為負。
- 基礎規則必守：
SELECT 具體列、利用索引列、必要時才 JOIN。
八、盡可能使用綁定變量
- 應用層 SQL 必須用綁定變量（
:b1、?），減少硬解析、提升擴展性、防止注入。
- 僅極少數「極度歪斜值需動態計劃」場景考慮字面量（配合 Histogram/ACS）。
九、使用源碼控制工具
- Git/SVN 管理 SQL/PLSQL 腳本，記錄變更歷史、作者、意圖。
- 代碼評審機制：核心 SQL 必須經過 Review 才能上線。
十、測試、測試、測試
- 功能測試：邊界值、NULL、空集合、大數據量、並發模擬。
- 性能測試：EXPLAIN PLAN、AUTOTRACE、SQL Monitor、真實數據量壓測。
- 回歸測試：變更後驗證相關報表/業務無副作用。
附錄：快速自查清單
[ ] 需求文檔齊全
[ ] 復用現有模板/視圖/包
[ ] 無過度復雜語法
[ ] NULL 邏輯正確 (IS NULL / NVL)
[ ] 類型顯式匹配，無隱式轉換
[ ] UNION ALL vs UNION 選擇正確
[ ] 綁定變量全覆蓋
[ ] 代碼已提交 Git 並 Review
[ ] 核心場景已壓測通過
[ ] 回歸驗證無衝突
將這 10 條鐵律內化為團隊編碼文化，SQL 質量將獲得質的飛躍，生產故障率大幅下降，維護成本顯著降低。
