您的位置：首页 > 数据库

十步完全理解SQL

2016-01-22 00:00 281 查看

摘要:很多程序员视SQL为洪水猛兽。SQL是一种为数不多的声明性语言，它的运行方式完全不同于我们所熟知的命令行语言、面向对象的程序语言、甚至是函数语言（尽管有些人认为SQL语言也是一种函数式语言）。我们每天都在写SQL并且应用在开源软件jOOQ中。于是我想把SQL...

很多程序员视SQL为洪水猛兽。SQL是一种为数不多的声明性语言，它的运行方式完全不同于我们所熟知的命令行语言、面向对象的程序语言、甚至是函数语言（尽管有些人认为SQL语言也是一种函数式语言）。

我们每天都在写SQL并且应用在开源软件jOOQ中。于是我想把SQL之美介绍给那些仍然对它头疼不已的朋友，所以本文是为了以下读者而特地编写的：

1、在工作中会用到SQL但是对它并不完全了解的人。

2、能够熟练使用SQL但是并不了解其语法逻辑的人。

3、想要教别人SQL的人。

本文着重介绍SELECT句式，其他的DML（DataManipulationLanguage数据操纵语言命令）将会在别的文章中进行介绍。

10个简单步骤，完全理解SQL

1、SQL是一种声明式语言

首先要把这个概念记在脑中：“声明”。SQL语言是为计算机声明了一个你想从原始数据中获得什么样的结果的一个范例，而不是告诉计算机如何能够得到结果。这是不是很棒？

（译者注：简单地说，SQL语言声明的是结果集的属性，计算机会根据SQL所声明的内容来从数据库中挑选出符合声明的数据，而不是像传统编程思维去指示计算机如何操作。）

SELECTfirst_name,last_nameFROMemployeesWHEREsalary>100000

上面的例子很容易理解，我们不关心这些雇员记录从哪里来，我们所需要的只是那些高薪者的数据（译者注：salary>100000）。

我们从哪儿学习到这些

如果SQL语言这么简单，那么是什么让人们“闻SQL色变”？主要的原因是：我们潜意识中的是按照命令式编程的思维方式思考问题的。就好像这样：“电脑，先执行这一步，再执行那一步，但是在那之前先检查一下是否满足条件A和条件B”。例如，用变量传参、使用循环语句、迭代、调用函数等等，都是这种命令式编程的思维惯式。

2、SQL的语法并不按照语法顺序执行

SQL语句有一个让大部分人都感到困惑的特性，就是：SQL语句的执行顺序跟其语句的语法顺序并不一致。SQL语句的语法顺序是：

SELECT[DISTINCT]

FROM

WHERE

GROUPBY

HAVING

UNION

ORDERBY

为了方便理解，上面并没有把所有的SQL语法结构都列出来，但是已经足以说明SQL语句的语法顺序和其执行顺序完全不一样，就以上述语句为例，其执行顺序为：

FROM

WHERE

GROUPBY

HAVING

SELECT

DISTINCT

UNION

ORDERBY

关于SQL语句的执行顺序，有三个值得我们注意的地方：

1、FROM才是SQL语句执行的第一步，并非SELECT。数据库在执行SQL语句的第一步是将数据从硬盘加载到数据缓冲区中，以便对这些数据进行操作。（译者注：原文为“Thefirstthingthathappensisloadingdatafromthediskintomemory,inordertooperateonsuchdata.”，但是并非如此，以Oracle等常用数据库为例，数据是从硬盘中抽取到数据缓冲区中进行操作。）

2、SELECT是在大部分语句执行了之后才执行的，严格的说是在FROM和GROUPBY之后执行的。理解这一点是非常重要的，这就是你不能在WHERE中使用在SELECT中设定别名的字段作为判断条件的原因。

SELECTA.x+A.yASz
FROMA
WHEREz=10
--z在此处不可用，因为SELECT是最后执行的语句！

如果你想重用别名z，你有两个选择。要么就重新写一遍z所代表的表达式：

SELECTA.x+A.yASz
FROMA
WHERE(A.x+A.y)=10

…或者求助于衍生表、通用数据表达式或者视图，以避免别名重用。请看下文中的例子。

3、无论在语法上还是在执行顺序上，UNION总是排在在ORDERBY之前。很多人认为每个UNION段都能使用ORDERBY排序，但是根据SQL语言标准和各个数据库SQL的执行差异来看，这并不是真的。尽管某些数据库允许SQL语句对子查询（subqueries）或者派生表（derivedtables）进行排序，但是这并不说明这个排序在UNION操作过后仍保持排序后的顺序。

注意：并非所有的数据库对SQL语句使用相同的解析方式。如MySQL、PostgreSQL和SQLite中就不会按照上面第二点中所说的方式执行。

我们学到了什么？

既然并不是所有的数据库都按照上述方式执行SQL预计，那我们的收获是什么？我们的收获是永远要记得：SQL语句的语法顺序和其执行顺序并不一致，这样我们就能避免一般性的错误。如果你能记住SQL语句语法顺序和执行顺序的差异，你就能很容易的理解一些很常见的SQL问题。

当然，如果一种语言被设计成语法顺序直接反应其语句的执行顺序，那么这种语言对程序员是十分友好的，这种编程语言层面的设计理念已经被微软应用到了LINQ语言中。

3、SQL语言的核心是对表的引用（tablereferences）

由于SQL语句语法顺序和执行顺序的不同，很多同学会认为SELECT中的字段信息是SQL语句的核心。其实真正的核心在于对表的引用。

根据SQL标准，FROM语句被定义为：

<fromclause>::=FROM<tablereference>[{<comma><tablereference>}...]

FROM语句的“输出”是一张联合表，来自于所有引用的表在某一维度上的联合。我们们慢慢来分析：

FROMa,b

上面这句FROM语句的输出是一张联合表，联合了表a和表b。如果a表有三个字段，b表有5个字段，那么这个“输出表”就有8（=5+3）个字段。

这个联合表里的数据是ab，即a和b的笛卡尔积。换句话说，也就是a表中的每一条数据都要跟b表中的每一条数据配对。如果a表有3条数据，b表有5条数据，那么联合表就会有15（=53）条数据。

FROM输出的结果被WHERE语句筛选后要经过GROUPBY语句处理，从而形成新的输出结果。我们后面还会再讨论这方面问题。

如果我们从集合论（关系代数）的角度来看，一张数据库的表就是一组数据元的关系，而每个SQL语句会改变一种或数种关系，从而产生出新的数据元的关系（即产生新的表）。

我们学到了什么？

思考问题的时候从表的角度来思考问题提，这样很容易理解数据如何在SQL语句的“流水线”上进行了什么样的变动。

4、灵活引用表能使SQL语句变得更强大

灵活引用表能使SQL语句变得更强大。一个简单的例子就是JOIN的使用。严格的说JOIN语句并非是SELECT中的一部分，而是一种特殊的表引用语句。SQL语言标准中表的连接定义如下：

<tablereference>::=
<tablename>
|<derivedtable>
|<joinedtable>

就拿之前的例子来说：

FROMa,b

a可能输如下表的连接：

a1JOINa2ONa1.id=a2.id

将它放到之前的例子中就变成了：

FROMa1JOINa2ONa1.id=a2.id,b

尽管将一个连接表用逗号跟另一张表联合在一起并不是常用作法，但是你的确可以这么做。结果就是，最终输出的表就有了a1+a2+b个字段了。

（译者注：原文这里用词为degree，译为维度。如果把一张表视图化，我们可以想象每一张表都是由横纵两个维度组成的，横向维度即我们所说的字段或者列，英文为columns；纵向维度即代表了每条数据，英文为record，根据上下文，作者这里所指的应该是字段数。）

在SQL语句中派生表的应用甚至比表连接更加强大，下面我们就要讲到表连接。

我们学到了什么？

思考问题时，要从表引用的角度出发，这样就很容易理解数据是怎样被SQL语句处理的，并且能够帮助你理解那些复杂的表引用是做什么的。

更重要的是，要理解JOIN是构建连接表的关键词，并不是SELECT语句的一部分。有一些数据库允许在INSERT、UPDATE、DELETE中使用JOIN。

5、SQL语句中推荐使用表连接

我们先看看刚刚这句话：

FROMa,b

高级SQL程序员也许学会给你忠告：尽量不要使用逗号来代替JOIN进行表的连接，这样会提高你的SQL语句的可读性，并且可以避免一些错误。

利用逗号来简化SQL语句有时候会造成思维上的混乱，想一下下面的语句：

FROMa,b,c,d,e,f,g,h
WHEREa.a1=b.bx
ANDa.a2=c.c1
ANDd.d1=b.bc
--etc...

我们不难看出使用JOIN语句的好处在于：

安全。JOIN和要连接的表离得非常近，这样就能避免错误

更多连接的方式，JOIN语句能去区分出来外连接和内连接等

我们学到了什么？

记着要尽量使用JOIN进行表的连接，永远不要在FROM后面使用逗号连接表。

6、SQL语句中不同的连接操作

SQL语句中，表连接的方式从根本上分为五种：

EQUIJOIN

SEMMIJOIN

ANTIJOIN

CROSSJOIN

DIVISION

EQUIJOIN

这是一种最普通的JOIN操作，它包含两种连接方式：

INNERJOIN（或者是JOIN）

OUTERJOIN（包括：LEFT、RIGHT、FULLOUTERJOIN）

用例子最容易说明其中区别：

--Thistablereferencecontainsauthorsandtheirbooks.
--Thereisonerecordforeachbookanditsauthor.
--authorswithoutbooksareNOTincluded
authorJOINbookONauthor.id=book.author_id

--Thistablereferencecontainsauthorsandtheirbooks
--Thereisonerecordforeachbookanditsauthor.
--...ORthereisan"empty"recordforauthorswithoutbooks
--("empty"meaningthatallbookcolumnsareNULL)
authorLEFTOUTERJOINbookONauthor.id=book.author_id

SEMIJOIN

这种连接关系在SQL中有两种表现方式：使用IN，或者使用EXISTS。“SEMI”在拉丁文中是“半”的意思。这种连接方式是只连接目标表的一部分。这是什么意思呢？再想一下上面关于作者和书名的连接。我们想象一下这样的情况：我们不需要作者/书名这样的组合，只是需要那些在书名表中的书的作者信息。那我们就能这么写：

--UsingIN
FROMauthor
WHEREauthor.idIN(SELECTbook.author_idFROMbook)

--UsingEXISTS
FROMauthor
WHEREEXISTS(SELECT1FROMbookWHEREbook.author_id=author.id)

尽管没有严格的规定说明你何时应该使用IN，何时应该使用EXISTS，但是这些事情你还是应该知道的：

IN比EXISTS的可读性更好

EXISTS比IN的表达性更好（更适合复杂的语句）

二者之间性能没有差异（但对于某些数据库来说性能差异会非常大）

因为使用INNERJOIN也能得到书名表中书所对应的作者信息，所以很多初学者机会认为可以通过DISTINCT进行去重，然后将SEMIJOIN语句写成这样：

--Findonlythoseauthorswhoalsohavebooks
SELECTDISTINCTfirst_name,last_name
FROMauthor
JOINbookONauthor.id=book.author_id

这是一种很糟糕的写法，原因如下：

SQL语句性能低下：因为去重操作（DISTINCT）需要数据库重复从硬盘中读取数据到内存中。（译者注：DISTINCT的确是很耗费资源的操作，但是每种数据库对于DISTINCT的操作方式可能不同）。

这么写并非完全正确：尽管也许现在这么写不会出现问题，但是随着SQL语句变得越来越复杂你想要去重得到正确的结果就变得十分困难。

更多的关于滥用DISTINCT的危害可以参考这篇博文

http://blog.jooq.org/2013/07/30/10-common-mistakes-java-developers-make-when-writing-sql/

ANTIJOIN

这种连接的关系跟SEMIJOIN刚好相反。在IN或者EXISTS前加一个NOT关键字就能使用这种连接。举个例子来说，我们列出书名表里没有书的作者：

--UsingIN
FROMauthor
WHEREauthor.idNOTIN(SELECTbook.author_idFROMbook)

--UsingEXISTS
FROMauthor
WHERENOTEXISTS(SELECT1FROMbookWHEREbook.author_id=author.id)

关于性能、可读性、表达性等特性也完全可以参考SEMIJOIN。

这篇博文介绍了在使用NOTIN时遇到NULL应该怎么办，因为有一点背离本篇主题，就不详细介绍，有兴趣的同学可以读一下

http://blog.jooq.org/2012/01/27/sql-incompatibilities-not-in-and-null-values/

CROSSJOIN

这个连接过程就是两个连接的表的乘积：即将第一张表的每一条数据分别对应第二张表的每条数据。我们之前见过，这就是逗号在FROM语句中的用法。在实际的应用中，很少有地方能用到CROSSJOIN，但是一旦用上了，你就可以用这样的SQL语句表达：

--Combineeveryauthorwitheverybook
authorCROSSJOINbook

DIVISION

DIVISION的确是一个怪胎。简而言之，如果JOIN是一个乘法运算，那么DIVISION就是JOIN的逆过程。DIVISION的关系很难用SQL表达出来，介于这是一个新手指南，解释DIVISION已经超出了我们的目的。但是有兴趣的同学还是可以来看看这三篇文章

http://blog.jooq.org/2012/03/30/advanced-sql-relational-division-in-jooq/

http://blog.jobbole.com/55086/#Division

https://www.simple-talk.com/sql/t-sql-programming/divided-we-stand-the-sql-of-relational-division/

7、SQL中如同变量的派生表

在这之前，我们学习到过SQL是一种声明性的语言，并且SQL语句中不能包含变量。但是你能写出类似于变量的语句，这些就叫做派生表：

说白了，所谓的派生表就是在括号之中的子查询：

--Aderivedtable
FROM(SELECT*FROMauthor)

需要注意的是有些时候我们可以给派生表定义一个相关名（即我们所说的别名）。

--Aderivedtablewithanalias
FROM(SELECT*FROMauthor)a

派生表可以有效的避免由于SQL逻辑而产生的问题。举例来说：如果你想重用一个用SELECT和WHERE语句查询出的结果，这样写就可以（以Oracle为例）：

--Getauthors'firstandlastnames,andtheirageindays
SELECTfirst_name,last_name,age
FROM(
SELECTfirst_name,last_name,current_date-date_of_birthage
FROMauthor
)
--Iftheageisgreaterthan10000days
WHEREage>10000

需要我们注意的是：在有些数据库，以及SQL：1990标准中，派生表被归为下一级——通用表语句（commontableexperssion）。这就允许你在一个SELECT语句中对派生表多次重用。上面的例子就（几乎）等价于下面的语句：

WITHaAS(
SELECTfirst_name,last_name,current_date-date_of_birthage
FROMauthor
)
SELECT*
FROMa
WHEREage>10000

当然了，你也可以给“a”创建一个单独的视图，这样你就可以在更广泛的范围内重用这个派生表了。更多信息可以阅读下面的文章（http://en.wikipedia.org/wiki/View_%28SQL%29）。

我们学到了什么？

我们反复强调，大体上来说SQL语句就是对表的引用，而并非对字段的引用。要好好利用这一点，不要害怕使用派生表或者其他更复杂的语句。

8、SQL语句中GROUPBY是对表的引用进行的操作

让我们再回想一下之前的FROM语句：

FROMa,b

现在，我们将GROUPBY应用到上面的语句中：

GROUPBYA.x,A.y,B.z

上面语句的结果就是产生出了一个包含三个字段的新的表的引用。我们来仔细理解一下这句话：当你应用GROUPBY的时候，SELECT后没有使用聚合函数的列，都要出现在GROUPBY后面。（译者注：原文大意为“当你是用GROUPBY的时候，你能够对其进行下一级逻辑操作的列会减少，包括在SELECT中的列”）。

1、需要注意的是：其他字段能够使用聚合函数：

SELECTA.x,A.y,SUM(A.z)
FROMA
GROUPBYA.x,A.y

2.还有一点值得留意的是：MySQL并不坚持这个标准，这的确是令人很困惑的地方。（译者注：这并不是说MySQL没有GROUPBY的功能）但是不要被MySQL所迷惑。GROUPBY改变了对表引用的方式。你可以像这样既在SELECT中引用某一字段，也在GROUPBY中对其进行分组。

我们学到了什么？

GROUPBY，再次强调一次，是在表的引用上进行了操作，将其转换为一种新的引用方式。

9、SQL语句中的SELECT实质上是对关系的映射

我个人比较喜欢“映射”这个词，尤其是把它用在关系代数上。（译者注：原文用词为projection，该词有两层含义，第一种含义是预测、规划、设计，第二种意思是投射、映射，经过反复推敲，我觉得这里用映射能够更直观的表达出SELECT的作用）。一旦你建立起来了表的引用，经过修改、变形，你能够一步一步的将其映射到另一个模型中。SELECT语句就像一个“投影仪”，我们可以将其理解成一个将源表中的数据按照一定的逻辑转换成目标表数据的函数。

通过SELECT语句，你能对每一个字段进行操作，通过复杂的表达式生成所需要的数据。

SELECT语句有很多特殊的规则，至少你应该熟悉以下几条：

1.你仅能够使用那些能通过表引用而得来的字段；

2.如果你有GROUPBY语句，你只能够使用GROUPBY语句后面的字段或者聚合函数；

3.当你的语句中没有GROUPBY的时候，可以使用开窗函数代替聚合函数；

4.当你的语句中没有GROUPBY的时候，你不能同时使用聚合函数和其它函数；

5.有一些方法可以将普通函数封装在聚合函数中；……

一些更复杂的规则多到足够写出另一篇文章了。比如：为何你不能在一个没有GROUPBY的SELECT语句中同时使用普通函数和聚合函数？（上面的第4条）

原因如下：

1.凭直觉，这种做法从逻辑上就讲不通。

2.如果直觉不能够说服你，那么语法肯定能。SQL:1999标准引入了GROUPINGSETS，SQL：2003标准引入了groupsets:GROUPBY()。无论什么时候，只要你的语句中出现了聚合函数，而且并没有明确的GROUPBY语句，这时一个不明确的、空的GROUPINGSET就会被应用到这段SQL中。因此，原始的逻辑顺序的规则就被打破了，映射（即SELECT）关系首先会影响到逻辑关系，其次就是语法关系。（译者注：这段话原文就比较艰涩，可以简单理解如下：在既有聚合函数又有普通函数的SQL语句中，如果没有GROUPBY进行分组，SQL语句默认视整张表为一个分组，当聚合函数对某一字段进行聚合统计的时候，引用的表中的每一条record就失去了意义，全部的数据都聚合为一个统计值，你此时对每一条record使用其它函数是没有意义的）。

糊涂了？是的，我也是。我们再回过头来看点浅显的东西吧。

我们学到了什么？

SELECT语句可能是SQL语句中最难的部分了，尽管他看上去很简单。其他语句的作用其实就是对表的不同形式的引用。而SELECT语句则把这些引用整合在了一起，通过逻辑规则将源表映射到目标表，而且这个过程是可逆的，我们可以清楚的知道目标表的数据是怎么来的。

想要学习好SQL语言，就要在使用SELECT语句之前弄懂其他的语句，虽然SELECT是语法结构中的第一个关键词，但它应该是我们最后一个掌握的。

10、SQL语句中的几个简单的关键词：DISTINCT，UNION，ORDERBY和OFFSET

在学习完复杂的SELECT豫剧之后，我们再来看点简单的东西：

集合运算（DISTINCT和UNION）

排序运算（ORDERBY,OFFSET...FETCH）

集合运算（setoperation）：

集合运算主要操作在于集合上，事实上指的就是对表的一种操作。从概念上来说，他们很好理解：

DISTINCT在映射之后对数据进行去重

UNION将两个子查询拼接起来去重

UNIONALL将两个子查询拼接起来但不去重

EXCEPT将第二个子查询中的结果从第一个子查询中去掉

INTERSECT保留两个子查询中都有的结果并去重

排序运算（orderingoperation）：

排序运算跟逻辑关系无关。这是一个SQL特有的功能。排序运算不仅在SQL语句的最后，而且在SQL语句运行的过程中也是最后执行的。使用ORDERBY和OFFSET…FETCH是保证数据能够按照顺序排列的最有效的方式。其他所有的排序方式都有一定随机性，尽管它们得到的排序结果是可重现的。

OFFSET…SET是一个没有统一确定语法的语句，不同的数据库有不同的表达方式，如MySQL和PostgreSQL的LIMIT…OFFSET、SQLServer和Sybase的TOP…STARTAT等。具体关于OFFSET..FETCH的不同语法可以参考这篇文章

http://www.jooq.org/doc/3.1/manual/sql-building/sql-statements/select-statement/limit-clause/

让我们在工作中尽情的使用SQL！

正如其他语言一样，想要学好SQL语言就要大量的练习。上面的10个简单的步骤能够帮助你对你每天所写的SQL语句有更好的理解。另一方面来讲，从平时常见的错误中也能积累到很多经验。下面的两篇文章就是介绍一些JAVA和其他开发者所犯的一些常见的SQL错误：

10CommonMistakesJavaDevelopersMakewhenWritingSQL

10MoreCommonMistakesJavaDevelopersMakewhenWritingSQL

本译文转载自伯乐在线，原文请参考十步完全理解SQL。作者水果泡腾片。转载请注明原文链接]http://blog.jobbole.com/55086/

内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理

标签：

相关文章推荐

新的分享

章节导航