Java 程序员容易犯的10个SQL错误

java程序员编程时需要混合面向对象思维和一般命令式编程的方法，能否完美的将两者结合起来完全得依靠编程人员的水准：

• 技能(任何人都能容易学会命令式编程)
• 模式(有些人用“模式-模式”,举个例子,模式可以应用到任何地方，而且都可以归为某一类模式)
• 心境(首先，要写个好的面向对象程序是比命令式程序难的多，你得花费一些功夫)

但当java程序员写sql语句时，一切都不一样了。sql是说明性语言而非面向对象或是命令式编程语言。在sql中要写个查询语句是很简单的。但在java里类似的语句却不容易，因为程序员不仅要反复考虑编程范式，而且也要考虑算法的问题。

下面是java程序员在写sql时常犯的错误(没有特定的顺序)：

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相比union all还需要额外的关键字。如果sql标准已经规定了支持，那么可能会更好点。

• union（允许重复）
• union distinct (去除了重复)

移除重复行不仅很少需要（有时甚至是错的），而且对于带很多行的大数据集合会相当慢，因为两个子select需要排序，而且每个元组也需要和它的子序列元组比较。

注意即使sql标准规定了intersect all和except all，很少数据库会实现这些没用的集合操作符。

处理方法：

每次你写union语句时，考虑实际上是否需要union all语句。

4.通过jdbc分页技术给大量的结果进行分页操作

大部分的数据库都会支持一些分页命令实现分页效果，譬如limit..offset,top..start at,offset..fetch语句等。即使没有支持这些语句的数据库，仍有可能对rownum（甲骨文）或者是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查询。

但是在sql：2003中定义了窗口函数，这个在很多主流数据库都实现了它。窗口函数能够在结果集上聚合数据，但是却没有分组。事实上，每个窗口函数都有自己的、独立的partition by语句，这个工具对于显示报告太tm好了。

使用窗口函数：

• 使sql更易读（但在子查询中没有group by语句专业）
• 提升性能，像关系数据库管理系统能够更容易优化窗口函数

解决方法：

当你在子查询中使用group by语句时，请再三考虑是否可以使用窗口函数完成。

9. 使用内存间接排序

sql的order by语句支持很多类型的表达式，包括case语句，对于间接排序十分有用。你可能重来不会在java内存中排序数据，因为你会想：

• sql排序很慢
• sql排序办不到

处理方法:

如果你在内存中排序任何sql数据，请再三考虑，是否不能在数据库中排序。这对于数据库分页数据十分有用。

10. 一条一条的插入大量纪录

jdbc ”懂“批处理(batch),你应该不会忘了它。不要使用insert语句来一条一条的出入成千上万的记录，（因为）每次都会创建一个新的preparedstatement对象。如果你的所有记录都插入到同一个表时，那么就创建一个带有一条sql语句以及附带很多值集合的插入批处理语句。你可能需要在达到一定量的插入记录后才提交来保证undo日志瘦小，这依赖于你的数据库和数据库设置。

关注流行国外网站

facebook:http://www.fb-on.com

facebook官网:http://www.facebookzh.com

facebook:http://www.cn-face-book.com

youtube:http://www.youtubezh.com

twitter:http://www.twitterzh.com

处理方法：

总是使用批处理插入大量数据。

以上就是本文的全部内容，希望本文的内容对大家的学习或者工作能带来一定的帮助，同时也希望多多支持！