Java程序員編程時需要混合面向對象思維和一般命令式編程的方法，能否完美的將兩者結合起來完全得依靠編程人員的水準：
- 技能（任何人都能容易學會命令式編程）
- 模式（有些人用“模式-模式”,舉個例子,模式可以應用到任何地方，而且都可以歸爲某一類模式）
- 心境（首先，要寫個好的面向對象程序是比命令式程序難的多，你得花費一些功夫）
但當Java程序員寫SQL語句時，一切都不一樣了。SQL是說明性語言而非面向對象或是命令式編程語言。在SQL中要寫個查詢語句是很簡單的。但在Java裏類似的語句卻不容易，因爲程序員不僅要反覆考慮編程範式，而且也要考慮算法的問題。
下面是Java程序員在寫SQL時常犯的10個錯誤（沒有特定的順序）。
1、忘掉NULL
Java程序員寫SQL時對NULL的誤解可能是最大的錯誤。也許是因爲（並非唯一理由）NULL也稱作UNKNOWN。如果被稱作 UNKNOWN，這還好理解些。另一個原因是，當你從數據庫拿東西或是綁定變量時，JDBC將SQL NULL 和Java中的null對應了起來。這樣導致了NULL = NULL（SQL）和null=null（Java）的誤解。
對於NULL最大的誤解是當NULL被用作行值表達式完整性約束條件時。另一個誤解出現在對於NULL 在 NOT IN anti-joins的應用中。
解決方法：
- 好好的訓練你自己。當你寫SQL時要不停得想到NULL的用法：
- 這個NULL完整性約束條件是正確的？
- NULL是否影響到結果？
2、在Java內存中處理數據
很少有Java開發者能將SQL理解的很好。偶爾使用的JOIN,還有古怪的UNION，好吧，但是對於窗口函數呢？還有對集合進行分組呢？許多 的Java開發者將SQL數據加載到內存中，將這些數據轉換成某些相近的集合類型，然後再那些集合上面使用邊界循環控制結構（至少在Java8的集合升級 以前）執行令人生厭的數學運算。
但是一些SQL數據庫支持先進的（而且是SQL標準支持的）OLAP特性,這一特性表現更好而且寫起來也更加方便。一個（並不怎麼標準的）例子就 是Oracle超棒的MODEL分句。只讓數據庫來做處理然後只把結果帶到Java內存中吧。因爲畢竟所有非常聰明的傢伙已經對這些昂貴的產品進行了優 化。因此實際上,通過將OLAP移到數據庫，你將獲得一下兩項好處：
- 便利性。這比在Java中編寫正確的SQL可能更加的容易。
- 性能表現。數據庫應該比你的算法處理起來更加快.而且更加重要的是,你不必再去傳遞數百萬條記錄了。
解決方法：
每次你使用Java實現一個以數據爲中心的算法時，問問自己：有沒有一種方法可以讓數據庫代替爲我做這種麻煩事。
3、使用UNION 代替UNION ALL
- UNION ALL（允許重複）
- UNION （去除了重複）
移除重複行不僅很少需要（有時甚至是錯的），而且對於帶很多行的大數據集合會相當慢，因爲兩個子select需要排序，而且每個元組也需要和它的子序列元組比較。
注意即使SQL標準規定了INTERSECT ALL和EXCEPT ALL，很少數據庫會實現這些沒用的集合操作符。
解決方法：
每次寫UNION語句時，考慮實際上是否需要UNION ALL語句。
4、通過JDBC分頁技術給大量的結果進行分頁操作
大部分的數據庫都會支持一些分頁命令實現分頁效果，譬如LIMIT..OFFSET,TOP..START AT,OFFSET..FETCH語句等。即使沒有支持這些語句的數據庫，仍有可能對ROWNUM（Oracle）或者是ROW NUMBER()、OVER()過濾（DB2、SQL Server2008等），這些比在內存中實現分頁更快速。在處理大量數據中，效果尤其明顯。
解決方法：
僅僅使用這些語句，那麼一個工具（例如JOOQ）就可以模擬這些語句的操作。
5、在Java內存中加入數據
從SQL的初期開始，當在SQL中使用JOIN語句時，一些開發者仍舊有不安的感覺。這是源自對加入JOIN後會變慢的固有恐懼。
假如基於成本的 優化選擇去實現嵌套循環，在創建一張連接表源前，可能加載所有的表在數據庫內存中，這可能是真的。但是這事發生的概率太低了。通過合適的預測，約束和索 引，合併連接和哈希連接的操作都是相當的快。這完全是是關於正確元數據（在這裏我不能夠引用Tom Kyte的太多）。而且，可能仍然有不少的Java開發人員加載兩張表通過分開查詢到一個映射中，並且在某種程度上把他們加到了內存當中。
解決方法：
假如你在各個步驟中有從各種表的查詢操作，好好想想是否可以表達你的查詢操作在單條語句中。
6、在一個臨時的笛卡爾積集合中使用 DISTINCT 或 UNION 消除重複項
通過複雜的連接，人們可能會對SQL語句中扮演關鍵角色的所有關係失去概念。特別的，如果這涉及到多列外鍵關係的話，很有可能會忘記在JOIN .. ON子句中增加相關的判斷。這會導致重複的記錄，但或許只是在特殊的情況下。有些開發者因此可能選擇DISTINCT來消除這些重複記錄。從三個方面來說 這是錯誤的：
- 它（也許）解決了表面症狀但並沒有解決問題。它也有可能無法解決極端情況下的症狀。
- 對具有很多列的龐大的結果集合來說它很慢。DISTINCT要執行ORDER BY操作來消除重複。
- 對龐大的笛卡爾積集合來說它很慢，還是需要加載很多的數據到內存中。
解決方法：
根據經驗，如果你獲得了不需要的重複記錄，還是檢查你的JOIN判斷吧。可能在某個地方有一個很難覺察的笛卡爾積集合。
7、不使用MERGE語句
這並不是一個過失，但是可能是缺少知識或者對於強悍的MERGE語句信心不足。一些數據庫理解其它形式的更新插入（UPSERT）語句， 如 MYSQL的重複主鍵更新語句，但是MERGE在數據庫中確是很強大，很重要，以至於大肆擴展SQL標準，例如SQL SERVER。
解決方法：
如果你使用像聯合INSERT和UPDATE或者聯合SELECT .. FOR UPDATE然後在INSERT或UPDATE等更新插入時，請三思。你完全可以使用一個更簡單的MERGE語句來遠離冒險競爭條件。
8、使用聚合函數代替窗口函數（window functions）
在介紹窗口函數之前，在SQL中聚合數據意味着使用GROUP BY語句與聚合函數相映射。在很多情形下都工作得很好，如聚合數據需要濃縮常規數據，那麼就在join子查詢中使用group查詢。
但是在SQL2003中定義了窗口函數，這個在很多主流數據庫都實現了它。窗口函數能夠在結果集上聚合數據，但是卻沒有分組。事實上，每個窗口函數都有自己的、獨立的PARTITION BY語句，這個工具對於顯示報告太好了。
使用窗口函數：
- 使SQL更易讀（但在子查詢中沒有GROUP BY語句專業）
- 提升性能，像關係數據庫管理系統能夠更容易優化窗口函數
解決方法：
當你在子查詢中使用GROUP BY語句時，請再三考慮是否可以使用窗口函數完成。
9、使用內存間接排序
SQL的ORDER BY語句支持很多類型的表達式，包括CASE語句，對於間接排序十分有用。你可能重來不會在Java內存中排序數據，因爲你會想：
- SQL排序很慢
- SQL排序辦不到
解決方法：
如果你在內存中排序任何SQL數據，請再三考慮，是否不能在數據庫中排序。這對於數據庫分頁數據十分有用。
10、一條一條地插入大量記錄
JDBC“懂”批處理（batch），你應該不會忘了它。不要使用INSERT語句來一條一條的出入成千上萬的記錄，（因爲）每次都會創建一個新 的PreparedStatement對象。如果你的所有記錄都插入到同一個表時，那麼就創建一個帶有一條SQL語句以及附帶很多值集合的插入批處理語 句。你可能需要在達到一定量的插入記錄後才提交來保證UNDO日誌瘦小，這依賴於你的數據庫和數據庫設置。
解決方法：
總是使用批處理插入大量數據。
原文來源：http://blog.jooq.org/<br> 譯者：LianyouCQ, LeoXu, yale8848, 開源中國駐聯合國理事, super0555<br> 譯文：https://www.oschina.net/translate/10-common-mistakes-java-developers-make-when-writing-sql
近期熱文推薦：
1.600+ 道 Java面試題及答案整理(2021最新版)
2.終於靠開源項目弄到 IntelliJ IDEA 激活碼了，真香！
3.阿里 Mock 工具正式開源，幹掉市面上所有 Mock 工具！
4.Spring Cloud 2020.0.0 正式發佈，全新顛覆性版本！
覺得不錯，別忘了隨手點贊+轉發哦！