Java 程序员常犯的 10 个 SQL 错误！

柔光的暖阳◎ 2022-10-05 00:48 206阅读 0赞

![c4efe3a2a37b35fc894b88eca010f06b.png][]

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]表达式完整性约束条件时。另一个误解出现在对于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分页技术给大量的结果进行分页操作][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/  
译者：LianyouCQ, LeoXu, yale8848, 开源中国驻联合国理事, super0555  
译文：https://www.oschina.net/translate/10-common-mistakes-java-developers-make-when-writing-sql*

推荐好文

[强大，10k+点赞的 SpringBoot 后台管理系统竟然出了详细教程！][10k_ SpringBoot]

[分享一套基于SpringBoot和Vue的企业级中后台开源项目，代码很规范！][SpringBoot_Vue]

[能挣钱的，开源 SpringBoot 商城系统，功能超全，超漂亮][SpringBoot]![57f6e9345eafd70a67f8fcfeb6e64835.png][]

[c4efe3a2a37b35fc894b88eca010f06b.png]: /images/20221005/faeb844fbf6742dc903f3e68a2458988.png
[NULL]: http://mp.weixin.qq.com/s?__biz=MzU2MTI4MjI0MQ%3D%3D&chksm=fc798df4cb0e04e27f0c82c6ec11ae5c007d49035a4cf6fbf0dd11c8448b34daa4e895307288&idx=2&mid=2247491674&scene=21&sn=fd54d2ab3f4f892fb81763a8a5d0142d#wechat_redirect
[4_JDBC]: http://mp.weixin.qq.com/s?__biz=MzU2MTI4MjI0MQ%3D%3D&chksm=fc7996d3cb0e1fc5fcc37b3fab07ba09a7de888757d29e31ff0f03c91725500f3dac3ebb3eeb&idx=1&mid=2247498621&scene=21&sn=809d809b5da1cd1d90b9408e92ba1a05#wechat_redirect
[GROUP BY]: http://mp.weixin.qq.com/s?__biz=MzU2MTI4MjI0MQ%3D%3D&chksm=fc798a93cb0e03856aaedb8d0c4afb080b62ff54e55a8e21e84c090218a2a3eba543a586aff2&idx=2&mid=2247493437&scene=21&sn=c447d0cf2f1965aacd3cefef3bf75989#wechat_redirect
[10k_ SpringBoot]: http://mp.weixin.qq.com/s?__biz=MzI4Njc5NjM1NQ%3D%3D&chksm=ebd5c411dca24d07446a4f22772cd12d2cc1143b62eb922a14500ae981cd57fb850ef74ca257&idx=2&mid=2247498557&scene=21&sn=84902d7030e174e152615d8fae3755cc#wechat_redirect
[SpringBoot_Vue]: http://mp.weixin.qq.com/s?__biz=MzU2MTI4MjI0MQ%3D%3D&chksm=fc799be6cb0e12f0b58479f8b031bc5ae79efdca1880ff9b19f0a107c3a88c37b9596dc73203&idx=2&mid=2247497288&scene=21&sn=65d7111a19e920df1e9416959594b2f4#wechat_redirect
[SpringBoot]: http://mp.weixin.qq.com/s?__biz=MzU2MTI4MjI0MQ%3D%3D&chksm=fc799a9ccb0e138a64a2671f31b8d4be1b3c061a288f7b0d1d4af02a60c45a72231446b91e00&idx=2&mid=2247497522&scene=21&sn=c5b4e596be4ac7d7f293e7e2f0ea0769#wechat_redirect
[57f6e9345eafd70a67f8fcfeb6e64835.png]: /images/20221005/fce330078bc74728aff554737e27b46f.png