Name: SQL基础教程
ISBN: 9787115322692

作者: MICK
出版社: 人民邮电出版社
译者: 孙淼 / 罗勇
出版年: 2013-8-1
页数: 294
定价: CNY 69.00
装帧: 平装
丛书: 图灵程序设计丛书·数据库系列
ISBN: 9787115322692

豆瓣评分

9.0

209人评价

5星

59.3%
4星

32.5%
3星

4.8%
2星

1.9%
1星

1.4%

评价:

内容简介 · · · · · ·

本书介绍了关系数据库以及用来操作关系数据库的SQL语言的使用方法，提供了大量的示例程序和详实的操作步骤说明，读者可以亲自动手解决具体问题，循序渐进地掌握SQL的基础知识和技巧，切实提高自身的编程能力。在每章结尾备有习题，用来检验读者对该章内容的理解程度。另外本书还将重要知识点总结为“法则”，方便大家随时查阅。

本书适合完全没有或者具备较少编程和系统开发经验的初学者，也可以作为大中专院校的教材及企业新人的培训用书。

作者简介 · · · · · ·

MICK

日本资深数据库工程师，致力于商业智能和数据仓库的开发。为日本著名的IT杂志WEB+PRESS撰写专栏。著作有《达人SQL完全指南》、《达人SQL设计终极指南》，译著有《SQL谜题》、《SQL权威指南》等。

译者简介：

孙淼

专业从事对日软件设计和研发工作，曾于2007年至2009年赴日学习工作。精通J2EE和数据库开发，热衷于品尝和制作美食。

罗勇

专业从事对日软件设计和研发工作，曾于2007年至2009年赴日学习工作。精通J2EE和数据库开发。译有《NoSQL数据库入门》、《明解C语言》等。

目录 · · · · · ·

目录
前　言　　III
关于本书　　IV
读者对象　　IV
学习本书前的预备知识　　IV
本书涉及的关系数据库　　V
· · · · · · (更多)

"SQL基础教程"试读 · · · · · ·

数据库是什么数据库的结构 SQL 概要表的创建表的删除和更新本章重点本章介绍了数据库的构成和基本理论，以及数据库的实际应用。大家可以学习到如何对关系数据库中用来存储数据的表进行创建、更新和删除操作，同时还能掌握关系数据库专用的SQL 语句的书写方法和规则。 1-1 数据库是什么 ■我们身边的数据库 ■为什么DBMS那么重要 ■DBMS种类 1-2 数据库的结构 ■RDBM...

第1 章：数据库和SQL

· · · · · · (查看全部试读)

豆瓣成员常用的标签(共48个) · · · · · ·

SQL 数据库入门计算机编程数据分析标准SQL 图灵程序设计丛书

丛书信息

　　图灵程序设计丛书·数据库系列 (共51册), 这套丛书还有《SQL Server 2008实战》,《Oracle基础教程》,《SQL进阶教程》,《SQL Server编程必知必会》,《精通Oracle SQL（第2版）》等。

喜欢读"SQL基础教程"的人也喜欢的电子书 · · · · · ·

支持 Web、iPhone、iPad、Android 阅读器

: SQL必知必会（第4版）

12.00元

: 图解HTTP

19.99元

: 算法图解

24.99元

: Python编程：从入门到实践

44.50元

: 增长黑客：创业公司的用户与收入增长秘籍

2.99元

喜欢读"SQL基础教程"的人也喜欢 · · · · · ·

: SQL进阶教程

: Introduction to Machine Learning w...

: 利用Python进行数据分析

: 深入浅出JavaScript（中文版）

: 图解服务器端网络架构

: Python语言及其应用

: 深入浅出SQL（中文版）

: 正则表达式必知必会（修订版）

: Python编程快速上手

: 自制编译器

我来说两句

短评 · · · · · · ( 全部 99 条 )

SQL基础教程的话题 · · · · · · ( 全部条 )

什么是话题

无论是一部作品、一个人，还是一件事，都往往可以衍生出许多不同的话题。将这些话题细分出来，分别进行讨论，会有更多收获。

我要写书评

SQL基础教程的书评 · · · · · · ( 全部 8 条 )

如果说必学必会是小本的入门书籍，这本就是大本的

书名不坑爹，属于0基础入门书。比起经典的SQL必知必会，行文稍显罗嗦（前者则不需要的一概不说），但不过分。如果准备从本书开始系统学习SQL，还是很好的。本书值得称道的地方是，基于标准SQL 2003编写，但又给出不同数据库系统的代码差异，方便入门者（学标准SQL），或特... (展开)

0回应

猴子 2019-04-09 22:58:10 人民邮电出版社2017版

没有任何基础的人怎么学SQL？

很多人喜欢一上来就推荐好几本书，但是这些书晦涩难懂，对于初学者入门非常不友好。入门只需要一本书就够了，而不是多本。如果非要推荐一本书的话，我推荐推荐《SQL基础教程》（作者：Mick）。也有人推荐《sql必知必会》，但是对于零基础的朋友来说Mick的《sql基础教程》更容易... (展开)

0回应

水生木 2016-06-26 20:54:55

相比《SQL必知必会》，此书更适合入门

相比名气更大的《SQL必知必会》，此书更适合SQL入门。《SQL必知必会》在其前言总结优点是“SQL方面的书很多，共同特点是，讲授的内容太多了，多数人其实不需要了解那么多”，“很多图书讲的不是SQL本身，而是从数据库设计、规范化到关系数据库理论以及管理问题等，事无巨细都... (展开)

0回应

上午八点 2017-07-13 16:41:05

整体是本好书，不过变量命名给作者跪了。

整本书安排很好，一点点的循序渐进，很通俗易懂，内容对新手很友好，跟着实际操作会很有收获，但是唯一让我很恼火的就是作者的日语音译命名，hanbai_tanka 这名称谁能知道是销售单价的意思，变量命名为selling_price 或者简单点直接 price 很难吗，每次读到这些变量就要连蒙带... (展开)

3回应

清风 2016-03-29 22:17:25

入门很简单

不夸张的说，这是我看过的最好的一本讲解 SQL 基础的书 1. 全书结构极其清晰，想怎么查就怎么查 2. 全书没有一句废话，秉承了日本人务实的职业素养 3. 全书富有节奏感，没有云里雾里的大跨度，练习题答案讲解详实 4. 所有晦涩的知识点都做到了透彻的梳理明白 5. 书中所用数据... (展开)

0回应

Monkey.D.Law 2014-03-03 19:23:01

入门妥妥的

这篇书评可能有关键情节透露

看起来很快，3天不到能看完，算是快速入门比较好的书吧。优点就是，里面的知识实用于五个最常用的数据库，而且不同的地方有图标标示，以后自己学习某一个数据库应该会比较快缺点：有一些印刷错误，不过都蛮简单的，仔细看，很容易看的出来的。命名都是按... (展开)

0回应

雨天sleep 2016-07-05 00:33:00

6.2 exist谓词 7.1 intersect 公共部分 except 记录的减法 7.2 交叉联结 8 rank() / dense_rank() / row_number() over (partition by ** order by **) sum(**) over( ** ) ave(**) over(order by ** rows between 1 preceding and 1 following) (展开)

0回应

scshxfan 2016-11-18 08:18:27

作者讲解思路非常清晰

虽然这本书读完之后觉得内容没有涵盖自己想学的（比如触发器、存储过程）但是单纯从这本书来讲可以说把sql基础讲的非常明了然后课后题设计的非常好并且给出了答案和精心的解释应该说如果所有的教学书籍都做到这么好那就太棒了但是这种好书真的不可多得建议新手们仔细... (展开)

2 0回应

> 更多书评8篇

读书笔记 · · · · · · (共9篇)

我来写笔记

按有用程度
按页码先后
最新笔记

展开收起
第242页

这正是外联结的关键点。多出的 2 条记录是高压锅和圆珠笔，这 2 条记录在 ShopProduct 表中并不存在，也就是说，这 2 种商品在任何商店中都没有销售。由于内联结只能选取出同时存在于两张表中的数据，因此只在 Product 表中存在的 2 种商品并没有出现在结果之中。相反，对于外联结来说，只要数据存在于某一张表当中，就能够读取出来。在实际的业务中，例如想要生成固定行数的单据时，就需要使用外联结。如果使用内联结的...
2017-12-16 17:26

这正是外联结的关键点。多出的 2 条记录是高压锅和圆珠笔，这 2 条记录在 ShopProduct 表中并不存在，也就是说，这 2 种商品在任何商店中都没有销售。由于内联结只能选取出同时存在于两张表中的数据，因此只在 Product 表中存在的 2 种商品并没有出现在结果之中。相反，对于外联结来说，只要数据存在于某一张表当中，就能够读取出来。在实际的业务中，例如想要生成固定行数的单据时，就需要使用外联结。如果使用内联结的话，根据 SELECT 语句执行时商店库存状况的不同，结果的行数也会发生改变，生成的单据的版式也会受到影响，而使用外联结能够得到固定行数的结果。虽说如此，那些表中不存在的信息我们还是无法得到，结果中高压锅和圆珠笔的商店编号和商店名称都是 NULL（具体信息大家都不知道，真是无可奈何）。外联结名称的由来也跟 NULL 有关，即“结果中包含原表中不存在（在原表之外）的信息”。相反，只包含表内信息的联结也就被称为内联结了。

推荐

回应 2017-12-16 17:26
展开收起
第196页

COALESCE 是 SQL 特有的函数。该函数会返回可变参数 A 中左侧开始第 1个不是 NULL 的值。参数个数是可变的，因此可以根据需要无限增加。其实转换函数的使用还是非常频繁的。在 SQL 语句中将 NULL 转换为其他值时就会用到转换函数（代码清单 6-19、代码清单 6-20）。就像之前我们学习的那样，运算或者函数中含有 NULL 时，结果全都会变为 NULL。能够避免这种结果的函数就是 COALESCE。
2017-12-16 17:12

COALESCE 是 SQL 特有的函数。该函数会返回可变参数 A 中左侧开始第 1个不是 NULL 的值。参数个数是可变的，因此可以根据需要无限增加。其实转换函数的使用还是非常频繁的。在 SQL 语句中将 NULL 转换为其他值时就会用到转换函数（代码清单 6-19、代码清单 6-20）。就像之前我们学习的那样，运算或者函数中含有 NULL 时，结果全都会变为 NULL。能够避免这种结果的函数就是 COALESCE。

推荐

回应 2017-12-16 17:12
展开收起
第155页

之前我们说过，在 SELECT 语句中视图可以和表一样使用。那么，对于 INSERT、 DELETE、 UPDATE 这类更新语句（更新数据的 SQL）来说，会怎么样呢？实际上，虽然这其中有很严格的限制，但是某些时候也可以对视图进行更新。标准 SQL 中有这样的规定：如果定义视图的 SELECT 语句能够满足某些条件，那么这个视图就可以被更新。下面就给大家列举一些比较具有代表性的条件。 ① SELECT 子句中未使用 DISTINCT ② FROM 子句中只...
2017-12-16 16:58

之前我们说过，在 SELECT 语句中视图可以和表一样使用。那么，对于 INSERT、 DELETE、 UPDATE 这类更新语句（更新数据的 SQL）来说，会怎么样呢？实际上，虽然这其中有很严格的限制，但是某些时候也可以对视图进行更新。标准 SQL 中有这样的规定：如果定义视图的 SELECT 语句能够满足某些条件，那么这个视图就可以被更新。下面就给大家列举一些比较具有代表性的条件。 ① SELECT 子句中未使用 DISTINCT ② FROM 子句中只有一张表 ③ 未使用 GROUP BY 子句 ④ 未使用 HAVING 子句

推荐

回应 2017-12-16 16:58
展开收起
第106页

虽然条件分别写在 WHERE 子句和 HAVING 子句当中，但是条件的内容以及返回的结果都完全相同。因此，大家可能会觉得两种书写方式都没问题。如果仅从结果来看的话，确实如此。但笔者却认为，聚合键所对应的条件还是应该书写在 WHERE 子句之中。理由有两个。首先，根本原因是 WHERE 子句和 HAVING 子句的作用不同。如前所述， HAVING 子句是用来指定“组”的条件的。因此，“行”所对应的条件还是应该写在 WHERE 子句当中...
2017-12-16 16:24

虽然条件分别写在 WHERE 子句和 HAVING 子句当中，但是条件的内容以及返回的结果都完全相同。因此，大家可能会觉得两种书写方式都没问题。如果仅从结果来看的话，确实如此。但笔者却认为，聚合键所对应的条件还是应该书写在 WHERE 子句之中。理由有两个。首先，根本原因是 WHERE 子句和 HAVING 子句的作用不同。如前所述， HAVING 子句是用来指定“组”的条件的。因此，“行”所对应的条件还是应该写在 WHERE 子句当中。这样一来，书写出的 SELECT 语句不但可以分清两者各自的功能，理解起来也更加容易。 WHERE 子句 = 指定行所对应的条件 HAVING 子句 = 指定组所对应的条件其次，对初学者来说，研究 DBMS 的内部实现这一话题有些深奥，这里就不做介绍了，感兴趣的读者可以参考随后的专栏——WHERE 子句和 HAVING 子句的执行速度。
WHERE子句和HAVING子句的执行速度在 WHERE 子句和 HAVING 子句中都可以使用的条件，最好写在 WHERE 子句中的另一个理由与性能即执行速度有关系。由于性能不在本书介绍的范围之内，因此暂不进行说明。通常情况下，为了得到相同的结果，将条件写在 WHERE 子句中要比写在 HAVING 子句中的处理速度更快，返回结果所需的时间更短。为了理解其中原因，就要从 DBMS 的内部运行机制来考虑。使用 COUNT 函数等对表中的数据进行聚合操作时，DBMS 内部就会进行排序处理。排序处理是会大大增加机器负担的高负荷的处理 A。因此，只有尽可能减少排序的行数，才能提高处理速度。通过 WHERE 子句指定条件时，由于排序之前就对数据进行了过滤，因此能够减少排序的数据量。但 HAVING 子句是在排序之后才对数据进行分组的，因此与在 WHERE 子句中指定条件比起来，需要排序的数据量就会多得多。虽然 DBMS 的内部处理不尽相同，但是对于排序处理来说，基本上都是一样的。此外， WHERE 子句更具速度优势的另一个理由是，可以对 WHERE 子句指定条件所对应的列创建索引，这样也可以大幅提高处理速度。创建索引是一种非常普遍的提高 DBMS 性能的方法，效果也十分明显，这对 WHERE 子句来说也十分有利。

推荐

回应 2017-12-16 16:24

展开收起
第91页

使用GROUP BY子句可以像切蛋糕那样将表分割。通过使用聚合函数和 GROUP BY子句，可以根据“商品种类”或者“登记日期”等将表分割后再进行汇总。 ● 聚合键中包含NULL时，在结果中会以“不确定”行（空行）的形式表现出来。 ● 使用聚合函数和GROUP BY子句时需要注意以下4点。 ① 只能写在SELECT子句之中 ② GROUP BY子句中不能使用SELECT子句中列的别名 ③ GROUP BY子句的聚合结果是无序的 ④ WHERE子句中不能使用聚合函数
2017-12-16 16:11

使用GROUP BY子句可以像切蛋糕那样将表分割。通过使用聚合函数和 GROUP BY子句，可以根据“商品种类”或者“登记日期”等将表分割后再进行汇总。 ● 聚合键中包含NULL时，在结果中会以“不确定”行（空行）的形式表现出来。 ● 使用聚合函数和GROUP BY子句时需要注意以下4点。 ① 只能写在SELECT子句之中 ② GROUP BY子句中不能使用SELECT子句中列的别名 ③ GROUP BY子句的聚合结果是无序的 ④ WHERE子句中不能使用聚合函数

推荐

回应 2017-12-16 16:11
展开收起
第95页

SELECT 并用时 WHERE 和 GROUP BY的执行顺序 FROM → WHERE → GROUP BY → SELECT
2017-12-16 16:14

SELECT 并用时 WHERE 和 GROUP BY的执行顺序 FROM → WHERE → GROUP BY → SELECT

推荐

回应 2017-12-16 16:14
展开收起
第100页

但其实这个问题本身就是本末倒置的，我们应该考虑的是该 SELECT 语句是否满足需求。选择的标准其实非常简单，在“想要删除选择结果中的重复记录”时使用 DISTINCT，在“想要计算汇总结果”时使用 GROUP BY。不使用COUNT等聚合函数，而只使用GROUP BY子句的SELECT语句，会让人觉得非常奇怪，使人产生“到底为什么要对表进行分组呢？这样做有必要吗？”等疑问。
2017-12-16 16:18

但其实这个问题本身就是本末倒置的，我们应该考虑的是该 SELECT 语句是否满足需求。选择的标准其实非常简单，在“想要删除选择结果中的重复记录”时使用 DISTINCT，在“想要计算汇总结果”时使用 GROUP BY。不使用COUNT等聚合函数，而只使用GROUP BY子句的SELECT语句，会让人觉得非常奇怪，使人产生“到底为什么要对表进行分组呢？这样做有必要吗？”等疑问。

推荐

回应 2017-12-16 16:18
展开收起
第106页

虽然条件分别写在 WHERE 子句和 HAVING 子句当中，但是条件的内容以及返回的结果都完全相同。因此，大家可能会觉得两种书写方式都没问题。如果仅从结果来看的话，确实如此。但笔者却认为，聚合键所对应的条件还是应该书写在 WHERE 子句之中。理由有两个。首先，根本原因是 WHERE 子句和 HAVING 子句的作用不同。如前所述， HAVING 子句是用来指定“组”的条件的。因此，“行”所对应的条件还是应该写在 WHERE 子句当中...
2017-12-16 16:24

虽然条件分别写在 WHERE 子句和 HAVING 子句当中，但是条件的内容以及返回的结果都完全相同。因此，大家可能会觉得两种书写方式都没问题。如果仅从结果来看的话，确实如此。但笔者却认为，聚合键所对应的条件还是应该书写在 WHERE 子句之中。理由有两个。首先，根本原因是 WHERE 子句和 HAVING 子句的作用不同。如前所述， HAVING 子句是用来指定“组”的条件的。因此，“行”所对应的条件还是应该写在 WHERE 子句当中。这样一来，书写出的 SELECT 语句不但可以分清两者各自的功能，理解起来也更加容易。 WHERE 子句 = 指定行所对应的条件 HAVING 子句 = 指定组所对应的条件其次，对初学者来说，研究 DBMS 的内部实现这一话题有些深奥，这里就不做介绍了，感兴趣的读者可以参考随后的专栏——WHERE 子句和 HAVING 子句的执行速度。
WHERE子句和HAVING子句的执行速度在 WHERE 子句和 HAVING 子句中都可以使用的条件，最好写在 WHERE 子句中的另一个理由与性能即执行速度有关系。由于性能不在本书介绍的范围之内，因此暂不进行说明。通常情况下，为了得到相同的结果，将条件写在 WHERE 子句中要比写在 HAVING 子句中的处理速度更快，返回结果所需的时间更短。为了理解其中原因，就要从 DBMS 的内部运行机制来考虑。使用 COUNT 函数等对表中的数据进行聚合操作时，DBMS 内部就会进行排序处理。排序处理是会大大增加机器负担的高负荷的处理 A。因此，只有尽可能减少排序的行数，才能提高处理速度。通过 WHERE 子句指定条件时，由于排序之前就对数据进行了过滤，因此能够减少排序的数据量。但 HAVING 子句是在排序之后才对数据进行分组的，因此与在 WHERE 子句中指定条件比起来，需要排序的数据量就会多得多。虽然 DBMS 的内部处理不尽相同，但是对于排序处理来说，基本上都是一样的。此外， WHERE 子句更具速度优势的另一个理由是，可以对 WHERE 子句指定条件所对应的列创建索引，这样也可以大幅提高处理速度。创建索引是一种非常普遍的提高 DBMS 性能的方法，效果也十分明显，这对 WHERE 子句来说也十分有利。

推荐

回应 2017-12-16 16:24

展开收起
第242页

这正是外联结的关键点。多出的 2 条记录是高压锅和圆珠笔，这 2 条记录在 ShopProduct 表中并不存在，也就是说，这 2 种商品在任何商店中都没有销售。由于内联结只能选取出同时存在于两张表中的数据，因此只在 Product 表中存在的 2 种商品并没有出现在结果之中。相反，对于外联结来说，只要数据存在于某一张表当中，就能够读取出来。在实际的业务中，例如想要生成固定行数的单据时，就需要使用外联结。如果使用内联结的...
2017-12-16 17:26

这正是外联结的关键点。多出的 2 条记录是高压锅和圆珠笔，这 2 条记录在 ShopProduct 表中并不存在，也就是说，这 2 种商品在任何商店中都没有销售。由于内联结只能选取出同时存在于两张表中的数据，因此只在 Product 表中存在的 2 种商品并没有出现在结果之中。相反，对于外联结来说，只要数据存在于某一张表当中，就能够读取出来。在实际的业务中，例如想要生成固定行数的单据时，就需要使用外联结。如果使用内联结的话，根据 SELECT 语句执行时商店库存状况的不同，结果的行数也会发生改变，生成的单据的版式也会受到影响，而使用外联结能够得到固定行数的结果。虽说如此，那些表中不存在的信息我们还是无法得到，结果中高压锅和圆珠笔的商店编号和商店名称都是 NULL（具体信息大家都不知道，真是无可奈何）。外联结名称的由来也跟 NULL 有关，即“结果中包含原表中不存在（在原表之外）的信息”。相反，只包含表内信息的联结也就被称为内联结了。

推荐

回应 2017-12-16 17:26
展开收起
第196页

COALESCE 是 SQL 特有的函数。该函数会返回可变参数 A 中左侧开始第 1个不是 NULL 的值。参数个数是可变的，因此可以根据需要无限增加。其实转换函数的使用还是非常频繁的。在 SQL 语句中将 NULL 转换为其他值时就会用到转换函数（代码清单 6-19、代码清单 6-20）。就像之前我们学习的那样，运算或者函数中含有 NULL 时，结果全都会变为 NULL。能够避免这种结果的函数就是 COALESCE。
2017-12-16 17:12

COALESCE 是 SQL 特有的函数。该函数会返回可变参数 A 中左侧开始第 1个不是 NULL 的值。参数个数是可变的，因此可以根据需要无限增加。其实转换函数的使用还是非常频繁的。在 SQL 语句中将 NULL 转换为其他值时就会用到转换函数（代码清单 6-19、代码清单 6-20）。就像之前我们学习的那样，运算或者函数中含有 NULL 时，结果全都会变为 NULL。能够避免这种结果的函数就是 COALESCE。

推荐

回应 2017-12-16 17:12
展开收起
第155页

之前我们说过，在 SELECT 语句中视图可以和表一样使用。那么，对于 INSERT、 DELETE、 UPDATE 这类更新语句（更新数据的 SQL）来说，会怎么样呢？实际上，虽然这其中有很严格的限制，但是某些时候也可以对视图进行更新。标准 SQL 中有这样的规定：如果定义视图的 SELECT 语句能够满足某些条件，那么这个视图就可以被更新。下面就给大家列举一些比较具有代表性的条件。 ① SELECT 子句中未使用 DISTINCT ② FROM 子句中只...
2017-12-16 16:58

之前我们说过，在 SELECT 语句中视图可以和表一样使用。那么，对于 INSERT、 DELETE、 UPDATE 这类更新语句（更新数据的 SQL）来说，会怎么样呢？实际上，虽然这其中有很严格的限制，但是某些时候也可以对视图进行更新。标准 SQL 中有这样的规定：如果定义视图的 SELECT 语句能够满足某些条件，那么这个视图就可以被更新。下面就给大家列举一些比较具有代表性的条件。 ① SELECT 子句中未使用 DISTINCT ② FROM 子句中只有一张表 ③ 未使用 GROUP BY 子句 ④ 未使用 HAVING 子句

推荐

回应 2017-12-16 16:58
展开收起
第106页

虽然条件分别写在 WHERE 子句和 HAVING 子句当中，但是条件的内容以及返回的结果都完全相同。因此，大家可能会觉得两种书写方式都没问题。如果仅从结果来看的话，确实如此。但笔者却认为，聚合键所对应的条件还是应该书写在 WHERE 子句之中。理由有两个。首先，根本原因是 WHERE 子句和 HAVING 子句的作用不同。如前所述， HAVING 子句是用来指定“组”的条件的。因此，“行”所对应的条件还是应该写在 WHERE 子句当中...
2017-12-16 16:24

虽然条件分别写在 WHERE 子句和 HAVING 子句当中，但是条件的内容以及返回的结果都完全相同。因此，大家可能会觉得两种书写方式都没问题。如果仅从结果来看的话，确实如此。但笔者却认为，聚合键所对应的条件还是应该书写在 WHERE 子句之中。理由有两个。首先，根本原因是 WHERE 子句和 HAVING 子句的作用不同。如前所述， HAVING 子句是用来指定“组”的条件的。因此，“行”所对应的条件还是应该写在 WHERE 子句当中。这样一来，书写出的 SELECT 语句不但可以分清两者各自的功能，理解起来也更加容易。 WHERE 子句 = 指定行所对应的条件 HAVING 子句 = 指定组所对应的条件其次，对初学者来说，研究 DBMS 的内部实现这一话题有些深奥，这里就不做介绍了，感兴趣的读者可以参考随后的专栏——WHERE 子句和 HAVING 子句的执行速度。
WHERE子句和HAVING子句的执行速度在 WHERE 子句和 HAVING 子句中都可以使用的条件，最好写在 WHERE 子句中的另一个理由与性能即执行速度有关系。由于性能不在本书介绍的范围之内，因此暂不进行说明。通常情况下，为了得到相同的结果，将条件写在 WHERE 子句中要比写在 HAVING 子句中的处理速度更快，返回结果所需的时间更短。为了理解其中原因，就要从 DBMS 的内部运行机制来考虑。使用 COUNT 函数等对表中的数据进行聚合操作时，DBMS 内部就会进行排序处理。排序处理是会大大增加机器负担的高负荷的处理 A。因此，只有尽可能减少排序的行数，才能提高处理速度。通过 WHERE 子句指定条件时，由于排序之前就对数据进行了过滤，因此能够减少排序的数据量。但 HAVING 子句是在排序之后才对数据进行分组的，因此与在 WHERE 子句中指定条件比起来，需要排序的数据量就会多得多。虽然 DBMS 的内部处理不尽相同，但是对于排序处理来说，基本上都是一样的。此外， WHERE 子句更具速度优势的另一个理由是，可以对 WHERE 子句指定条件所对应的列创建索引，这样也可以大幅提高处理速度。创建索引是一种非常普遍的提高 DBMS 性能的方法，效果也十分明显，这对 WHERE 子句来说也十分有利。

推荐

回应 2017-12-16 16:24