Java开发者写SQL时常犯的10个错误

- 导航条 -
首页
所有文章
资讯
Web
架构
基础技术
书籍
教程
我要投稿
更多频道 »
- iOS
- Python
- Android
- Web前端

Java开发者写SQL时常犯的10个错误

2015/03/10 | 分类： 基础技术 | 0 条评论 | 标签： SQL

分享到：0

本文由 ImportNew - zer0Black 翻译自 jooq。欢迎加入翻译小组。转载请见文末要求。

我十分惊讶的发现，我最近的一篇文章——《Java开发者写SQL时常犯的10个错误》——最近在我的博客和我的合作伙伴DZone上非常的受欢迎。（这篇博客）的流行程度说明了几件事：

  • SQL在专业的Java开发中多么重要。
  • 基本的SQL知识被忘掉（的情况）普遍存在。
  • 通过embracing SQL，你就能了解像 jOOQ或MyBatis这样的以SQL为中心的库正好反应了市场的需要。 令人惊喜的是有用户提到了我博客上贴的一篇“SLICK’s mailing list”，SLICK是Scala中的一个不以SQL为中心的数据库访问库，像LINQ（还有LINQ-to-SQL），它侧重语言整合，而不是SQL语句的产生。

无论如何，我之前仓促列出的常见错误还没列完。因此我为你另外准备了10个没那么常见的，但Java开发者在写SQL语句时同样爱犯的错误。

1、不用PreparedStatements

有意思的是，在JDBC出现了许多年后的今天，这个错误依然出现在博客、论坛和邮件列表中，即便要记住和理解它是一件很简单的事。开发者不使用PreparedStatements的原因可能有如下几个：

  • 他们对PreparedStatements不了解
  • 他们认为使用PreparedStatements太慢了
  • 他们认为写PreparedStatements太费力

来吧，我们来破除上面的谣言。96%的案例中，用PreparedStatement比静态声明语句更好。为什么呢？就是下面这些简单的原因：

  • 使用内联绑定值（inlining bind values）可以从源头上避免糟糕的语句引起语法错误。
  • 使用内联绑定值可以避免糟糕的语句引起的SQL注入漏洞。
  • 当插入更多“复杂的”数据类型（比如时间戳、二进制数据等等）时，可以避免边缘现象（edge-cases）。
  • 你若保持PreparedStatements的连接开启状态而不马上关闭，只要重新绑定新值就可以进行复用。
  • 你可以在更多复杂的数据库里使用adaptive cursor sharing——自适应游标共享（Oracle的说法）。这可以帮你在每次新设定绑定值时阻止SQL语句硬解析。

（译者注：硬解析的弊端。硬解析即整个SQL语句的执行需要完完全全的解析，生成执行计划。而硬解析，生成执行计划需要耗用CPU资源，以及SGA资源。在此不得不提的是对库缓存中 闩的使用。闩是锁的细化，可以理解为是一种轻量级的串行化设备。当进程申请到闩后，则这些闩用于保护共享内存的数在同一时刻不会被两个以上的进程修改。在 硬解析时，需要申请闩的使用，而闩的数量在有限的情况下需要等待。大量的闩的使用由此造成需要使用闩的进程排队越频繁，性能则逾低下）

某些特殊情况下你需要对值进行内联绑定，这是为了给基于成本的性能优化器提示该查询将要涉及的数据集。典型的情况是用“常量”判断：

  • DELETED = 1
  • STATUS = 42

而不应该用一个“变量”判断：

  • FIRST_NAME LIKE “Jon%”
  • AMOUNT > 19.95

要注意的是，现代数据库已经实现了绑定数据窥探（bind-variable peeking）。因此，默认情况下，你也可以为你所有的查询参数使用绑定值。在你写嵌入的JPQL或嵌入的SQL时，用JPA CriteriaQuery或者jOOQ这类高层次的API可以很容易也很清晰的帮你生成PreparedStatements语句并绑定值。

更多的背景资料：

解决方案：

默认情况下，总是使用PreparedStatements来代替静态声明语句，而永远不要在你的SQL语句嵌入内联绑定值。

2、返回太多列

这个错误发生的非常频繁，它不光会影响你的数据库执行计划，也会对你的Java应用造成不好的影响。让我们先看看对后者的影响：

对Java程序的不良影响:

如 果你为了满足不同DAO层之间的数据复用而select *或者默认的50个列，这样将会有大量的数据从数据库读入到JDBC结果集中，即使你不从结果集读取数据，它也被传递到了线路上并被JDBC驱动器加载到 了内存中。如果你知道你只需要2-3列数据的话，这就造成了严重的IO和内存的浪费。

这个（问题的严重性）都是显而易见的，要小心……

对数据库执行计划的不良影响：

这 些影响事实上可能比对Java应用的影响还要严重。当复杂的数据库要针对你的查询请求计算出最佳执行计划时，它会进行大量的SQL转换（SQL transformation ）。还好，请求中的一部分可以被略去，因为它们对SQL连映射或过滤条件起不了什么作用。我最近写了一篇博客来讲述这个问题：元数据模式会对Oracle查询转换产生怎样的影响。

现在，给你展示一个错误的例子。想一想有两个视图的复杂查询：


1

2

3

4

SELECT *

FROM  customer_view c

JOIN  order_view o

ON  c.cust_id = o.cust_id

每个关联了上述关联表引用的视图也可能再次关联其他表的数据，像 CUSTOMER_ADDRESS、ORDER_HISTORY、ORDER_SETTLEMENT等等。进行select * 映射时，你的数据库除了把所有连接表都加载进来以外别无选择，实际上，你唯一感兴趣的数据可能只有这些：


1

2

3

4

SELECT c.first_name, c.last_name, o.amount

FROM  customer_view c

JOIN  order_view o

ON  c.cust_id = o.cust_id

一个好的数据库会在转换你的SQL语句时自动移除那些不需要的连接，这样数据库就只需要较少的IO和内存消耗。

解决方案：

永远不要用select *（这样的查询）。也不要在执行不同请求时复用相同的映射。尽量尝试减少映射到你所真正需要的数据。

需要注意的是，想在对象-关系映射（ORMs）上达成这个目标有些难。

3、把JOIN当做了SELECT的子句

对于性能或SQL语句的正确性来说，这不算错。但是不管如何，SQL开发者应该意识到JOIN子句不是SELECT语句的一部分。SQL standard 1992 定义了表引用：


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

6.3 <table reference>

<table reference> ::=

<table name> [ [ AS ] <correlation name>

[ <left paren> <derived column list> <right paren> ] ]

| <derived table> [ AS ] <correlation name>

[ <left paren> <derived column list> <right paren> ]

| <joined table>

7.4 <from clause>

<from clause> ::=

FROM <table reference> [ { <comma> <table reference> }... ]

7.5 <joined table>

<joined table> ::=

<cross join>

| <qualified join>

| <left paren> <joined table> <right paren>

<cross join> ::=

<table reference> CROSS JOIN <table reference>

<qualified join> ::=

<table reference> [ NATURAL ] [ <join type> ] JOIN

<table reference> [ <join specification> ]

关联数据库是以表为中心的。许多的操作的某方面都是执行在物理表、连接表或派生表上的。为了有效的写出SQL语句，理解SELECT … FROM子句是以“，”分割表引用是非常重要的。

基于表引用（table references）的复杂性，一些数据库也接受其它类型的复杂的表引用（table references），像INSERT、UPDATE、DELETE、MERGE。看看Oracle实例手册，里面解释了如何创建可更新的视图。

解决方案：

一定要考虑到，一般说来，FROM子句也是一个表引用（table references）。如果你写了JOIN子句，要考虑这个JOIN子句是这个复杂的表引用的一部分：


1

2

3

4

SELECT c.first_name, c.last_name, o.amount

FROMcustomer_view c

JOIN order_view o

ON c.cust_id = o.cust_id

4、使用ANSI 92标准之前连接语法

我 们已经说清了表引用是怎么工作的（看上一节），因此我们应该达成共识，不论花费什么代价，都应该避免使用ANSI 92标准之前的语法。就执行计划而言，使用JOIN…ON子句或者WHERE子句来作连接谓语没有什么不同。但从可读性和可维护性的角度看，在过滤条 件判断和连接判断中用WHERE子句会陷入不可自拔的泥沼，看看这个简单的例子：


1

2

3

4

5

6

SELECT c.first_name, c.last_name, o.amount

FROM  customer_view c,

order_view o

WHERE  o.amount > 100

AND    c.cust_id = o.cust_id

AND    c.language = ‘en‘

你能找到join谓词么？如果我们加入数十张表呢？当你使用外连接专有语法的时候会变得更糟，就像Oracle的（+）语法里讲的一样。

解决方案：

一定要用ANSI 92标准的JOIN语句。不要把JOIN谓词放到WHERE子句中。用ANSI 92标准之前的JOIN语法没有半点好处。

5、使用LIKE判定时忘了ESCAPE

SQL standard 1992 指出like判定应该如下：


1

2

3

4

5

8.5 <like predicate>

<like predicate> ::=

<match value> [ NOT ] LIKE <pattern>

[ ESCAPE <escape character> ]

当允许用户对你的SQL查询进行参数输入时，就应该使用ESCAPE关键字。尽管数据中含有百分号（%）的情况很罕见，但下划线（_）还是很常见的：


1

2

3

SELECT *

FROM  t

WHERE  t.x LIKE ‘some!_prefix%‘ ESCAPE ‘!‘

解决方案：

使用LIKE判定时，也要使用合适的ESCAPE

6、认为 NOT (A IN (X, Y)) 和 IN (X, Y) 的布尔值相反

对于NULLs，这是一个举足轻重的细节！让我们看看 A IN (X, Y) 真正意思吧：

A IN (X, Y)
is the same as    A = ANY (X, Y)
is the same as    A = X OR A = Y

When at the same time, NOT (A IN (X, Y)) really means:

同样的，NOT (A IN (X, Y))的真正意思：

NOT (A IN (X, Y))
is the same as    A NOT IN (X, Y)
is the same as    A != ANY (X, Y)
is the same as    A != X AND A != Y

看起来和之前说的布尔值相反一样？其实不是。如果X或Y中任何一个为NULL，NOT IN 条件产生的结果将是UNKNOWN，但是IN条件可能依然会返回一个布尔值。

或者换种说话，当 A IN (X, Y) 结果为TRUE或FALSE时，NOT(A IN (X, Y)) 结果为依然UNKNOWN而不是FALSE或TRUE。注意了，如果IN条件的右边是一个子查询，结果依旧。

不信？你自己看SQL Fiddle 去。它说了如下查询给不出结果：


1

2

3

4

5

SELECT 1

WHERE    1 IN (NULL)

UNION ALL

SELECT 2

WHERE NOT(1 IN (NULL))

更多细节可以参考我的上一篇博客,上面写了在同区域内不兼容的一些SQL方言。

解决方案：

当涉及到可为NULL的列时，注意NOT IN条件。

7、认为NOT (A IS NULL)和A IS NOT NULL是一样的

没错，我们记得处理NULL值的时候，SQL实现了三值逻辑。这就是我们能用NULL条件来检测NULL值的原因。对么？没错。

但在NULL条件容易遗漏的情况下。要意识到下面这两个条件仅仅在行值表达式（row value expressions）为1的时候才相等：

NOT (A IS NULL)
is not the same as A IS NOT NULL

如果A是一个大于1的行值表达式（row value expressions），正确的表将按照如下方式转换：

  • 如果A的所有值为NUll，A IS NULL为TRUE
  • 如果A的所有值为NUll，NOT(A IS NULL) 为FALSE
  • 如果A的所有值都不是NUll，A IS NOT NULL 为TRUE
  • 如果A的所有值都不是NUll，NOT(A IS NOT NULL)  为FALSE

在我的上一篇博客可以了解到更多细节。

解决方案：

当使用行值表达式（row value expressions）时，要注意NULL条件不一定能达到预期的效果。

8、不用行值表达式

行值表达式是SQL一个很棒的特性。SQL是一个以表格为中心的语言，表格又是以行为中心。通过创建能在同等级或行类型进行比较的点对点行模型，行值表达式让你能更容易的描述复杂的判定条件。一个简单的例子是，同时请求客户的姓名


1

2

3

SELECT c.address

FROM  customer c,

WHERE (c.first_name, c.last_name) = (?, ?)

可以看出，就将每行的谓词左边和与之对应的右边比较这个语法而言，行值表达式的语法更加简洁。特别是在有许多独立条件通过AND连接的时候就特别有效。行值表达式允许你将相互联系的条件放在一起。对于有外键的JOIN表达式来说，它更有用：


1

2

3

4

SELECT c.first_name, c.last_name, a.street

FROM  customer c

JOIN  address a

ON  (c.id, c.tenant_id) = (a.id, a.tenant_id)

不幸的是，并不是所有数据库都支持行值表达式。但SQL标准已经在1992对行值表达式进行了定义，如果你使用他们，像Oracle或Postgres这些的复杂数据库可以使用它们计算出更好的执行计划。在Use The Index, Luke这个页面上有解析。

解决方案：

不管干什么都可以使用行值表达式。它们会让你的SQL语句更加简洁高效。

9、不定义足够的限制条件（constraints）

我又要再次引用Tom Kyte 和 Use The Index, Luke 了。对你的元数据使用限制条件不能更赞了。首先，限制条件可以帮你防止数据质变，光这一点就很有用。但对我来说更重要的是，限制条件可以帮助数据库进行SQL语句转换，数据库可以决定。

  • 哪些值是等价的
  • 哪些子句是冗余的
  • 哪些子句是无效的（例如，会返回空值的语句）

有些开发者可能认为限制条件会导致（数据库）变慢。但相反，除非你插入大量的数据，对于大型操作是你可以禁用限制条件，或用一个无限制条件的临时“载入表”，线下再把数据转移到真实的表中。

解决方案：

尽可能定义足够多的限制条件（constraints）。它们将帮你更好的执行数据库请求。

10、认为50ms是一个快的查询速度

NoSQL的炒作依然在继续，许多公司认为它们像Twitter或Facebook一样需要更快、扩展性更好的解决方案，想脱离ACID和关系模型横向扩展。有些可能会成功（比如Twitter或Facebook），而其他的也许会走入误区：

看这篇文章：https://twitter.com/codinghorror/status/347070841059692545。

对于那些仍被迫（或坚持）使用关系型数据 库的公司，请不要自欺欺人的认为：“现在的关系型数据库很慢，其实它们是被天花乱坠的宣传弄快的”。实际上，它们真的很快，解析20Kb查询文档，计算 2000行执行计划，如此庞大的执行，所需时间小于1ms，如果你和数据管理员（DBA）继续优化调整数据库，就能得到最大限度的运行。

它们会变慢的原因有两种：一是你的应用滥用流行的ORM；二是ORM无法针对你复杂的查询逻辑产生快的SQL语句。遇到这种情况，你就要考虑选择像 JDBC、jOOQ 或MyBatis这样的更贴近SQL核心，能更好的控制你的SQL语句的API。

因此，不要认为查询速度50ms是很快或者可以接受的。完全不是！如果你程序运行时间是这样的，请检查你的执行计划。这种潜在危险可能会在你执行更复杂的上下文或数据中爆发。

总结

SQL很有趣，同时在各种各样的方面也很微妙。正如我的关于10个错误的博客所展示的。跋山涉水也要掌握SQL是一件值得做的事。数据是你最有价值的资产。带着尊敬的心态对待你的数据才能写出更好的SQL语句。

时间： 2024-10-11 01:23:15

Java开发者写SQL时常犯的10个错误的相关文章

Java程序员常犯的10个错误

本文总结了Java程序员常犯的10个错误. #1. 把Array转化成ArrayList 把Array转化成ArrayList,程序员经常用以下方法: List<String> list = Arrays.asList(arr); Arrays.asList() 实际上返回一个ArrayList,但是这个ArrayList是Arrays的一个内部私有类,而不是java.util.ArrayList类.这个私有类java.util.Arrays.ArrayList有set(), get(), c

[转]Java程序员们最常犯的10个错误

1.将数组转化为列表 将数组转化为一个列表时,程序员们经常这样做: List<String> list = Arrays.asList(arr); Arrays.asList()会返回一个ArrayList对象,ArrayList类是Arrays的一个私有静态类,而不是java.util.ArrayList类,java.util.Arrays.ArrayList类有set().get().contains()方法,但是没有增加元素的方法,所以它的大小是固定的,想要创建一个真正的ArrayLis

Java程序员们最常犯的10个错误

1.将数组转化为列表 将数组转化为一个列表时,程序员们经常这样做: List list = Arrays.asList(arr); Arrays.asList()会返回一个ArrayList对象,ArrayList类是Arrays的一个私有静态类,而不是java.util.ArrayList类,java.util.Arrays.ArrayList类有set().get().contains()方法,但是没有增加元素的方法,所以它的大小是固定的,想要创建一个真正的ArrayList类,你应该这样做

Python开发者最常犯的10个错误

摘要:Python是一门简单易学的编程语言,语法简洁而清晰,并且拥有丰富和强大的类库.在日常开发中,开发者很容犯一些低级的错误,本文总结了开发者最容易犯的10个错误. Python是一门简单易学的编程语言,语法简洁而清晰,并且拥有丰富和强大的类库.与其它大多数程序设计语言使用大括号不一样 ,它使用缩进来定义语句块. 在平时的工作中,Python开发者很容易犯一些小错误,这些错误都很容易避免,本文总结了Python开发者最常犯的10个错误,一起来看下,不知你中枪了没有. 1.滥用表达式作为函数参数

C# 程序员最常犯的 10 个错误

关于C# C#是达成微软公共语言运行库(CLR)的少数语言中的一种.达成CLR的语言可以受益于其带来的特性,如跨语言集成.异常处理.安全性增强.部件组合的简易模型以及调试和分析服务.作为现代的CLR语言,C#是应用最为广泛的,其应用场景针对Windows桌面.移动手机以及服务器环境等复杂.专业的开发项目. C#是种面向对象的强类型语言.C#在编译和运行时都有的强类型检查,使在大多数典型的编程错误能够被尽早地发现,而且位置定位相当精准.相比于那些不拘泥类型,在违规操作很久后才报出可追踪到莫名其妙错

（转）C# 程序员易犯的 10 个错误

关于C# C#是针对微软公共语言运行库(CLR)的开发语言之一.针对CLR的开发语言得益于如跨语言集成的性能,异常处理,安全性增强,组件交互的简化模型,调试和分析服务.对于今日的CLR来说,C#是定位到Windows桌面,移动设备或服务器环境中,在处理复杂,专业的开发项目方面使用最广泛的开发语言. C#是面相对象,强类型的语言.C#中严格的类型检查,在编译和运行时,使得典型的编程错误能尽早报告,并且能精准给出错误位置.这能帮助程序员节省很多时间,相比于跟踪那些可以发生在违规操作很长时间之后的令人

Python 程序员经常犯的 10 个错误

关于PythonPython是一种解释性.面向对象并具有动态语义的高级程序语言.它内建了高级的数据结构,结合了动态类型和动态绑定的优点,这使得... 关于Python Python是一种解释性.面向对象并具有动态语义的高级程序语言.它内建了高级的数据结构,结合了动态类型和动态绑定的优点,这使得它在快速应用开发中非常有吸引力,并且可作为脚本或胶水语言来连接现有的组件或服务.Python支持模块和包,从而鼓励了程序的模块化和代码重用. 关于这篇文章 Python简单易学的语法可能会使Python开发

C语言编程时常犯十八个错误

C语言的最大特点是:功能强.使用方便灵活.C编译的程序对语法检查并不象其它高级语言那么严格,这就给编程人员留下"灵活的余地",但还是由于这个灵活给程序的调试带来了许多不便,尤其对初学C语言的人来说,经常会出一些连自己都不知道错在哪里的错误.看着有错的程序,不知该如何改起,本人通过对C的学习,积累了一些C编程时常犯的错误,写给各位学员以供参考.1.书写标识符时,忽略了大小写字母的区别.main(){ int a=5; printf("%d",A);}编译程序把a和A认

Web开发人员常犯的10个错误

说到开发一个运行在现代网络中的网站:Web开发人员需要选择虚拟主机平台和底层数据存储,准备编写HTML.CSS和JavaScript用的工具,要有设计执行方式,以及一些可用的JavaScript库/框架.在将任务分解为这几步之后,接下来要做的就简单多了,可以去网上找文章,浏览论坛,看看那些能提供更好的Web体验提示的示例. 然而不管是走哪条路,犯错却是每一个开发人员都不可避免的.虽然有些错误与某一个具体的行为相关,但有些错误却是所有Web开发人员都需要面对的挑战.因此,通过研究,体验和观察,我总