MySQL 超新手入门(5) JOIN 与 UNION 查询

简介: 在「world」资料库的「country」表格中,储存世界上所有的国家资料,其中有一个栏位「Capital」用来储存首都资料,不过它只是储存一个编号;另外在「city」表格中,储存世界上所有的城市资料,它主要的栏位有城市编号和城市的名称:

1 使用多个表格

在「world」资料库的「country」表格中,储存世界上所有的国家资料,其中有一个栏位「Capital」用来储存首都资料,不过它只是储存一个编号;另外在「city」表格中,储存世界上所有的城市资料,它主要的栏位有城市编号和城市的名称:

image.png

虽然「country」表格自己没有储存城市名称,不过它可以使用「Capital」栏位的值,对照到「city」表格中的「ID」栏位,也可以知道城市的名称。在这样的表格设计架构下,如果你想要查询「所有国家的首都名称」:

image.png

这样的查询需求就称为「结合查询」,也就是你要查询的资料,来自于一个以上的表格,而且两个表格之间具有上列讨论的「对照」情形。

2 Inner Join

「Inner join」通常称为「内部结合」,它可以应付大部份的结合查询需求,内部结合有两种写法,差异在把结合条件设定在「WHERE」子句或「FROM」子句中。


2.1 使用结合条件

下列是在「WHERE」子句中设定结合条件来执行结合查询的语法:

image.png

虽然这里会先介绍使用结合条件的结合查询,不过不管使用哪一种写法,在使用结合查询时都会有一样的想法。首先是你想要查询的栏位:

image.png

把需要查询的栏位列在「SELECT」之后,「FROM」子句后面该需要哪一些表格就很清楚了:

image.png

最后把表格与表格之间「对照」的结合条件放在「WHERE」子句中:

image.png

这样的叙述就可以查询「所有国家的首都名称」。


2.2 指定表格名称

在上列的讨论中,因为使用到多个表格了,所以在使用表格的栏位时,都特别提醒你要在栏位名称前面加上表格名称。其实并不是全部都要指定表格名称,你只有在一种情况下,才「一定要」在栏位名称前指定表格名称:

image.png

在查询叙述的「FROM」子句中用到的表格,如果有一样的栏位名称,而且你在查询叙述中也用到了这些栏位,就「一定要」在栏位名称前指定表格名称,否则都可以省略:

image.png

所以省略掉一些表格名称以后,查询叙述就简短多了,不过它执行查询后的结果也是一样的:

SELECT Code, Capital, city.Name

FROM country, city

WHERE Capital = ID

如果不小心违反上列的规则,你的查询叙述在执行以后就会发生错误:

image.png


2.3 表格别名

如果你想要查询「国家和首都的人口和比例」:

image.png

这样的结合查询刚好都使用到两个表格中,有同样名称的栏位,所以你一定要指定表格名称:

SELECT country.name, country.Population coPop,

city.Name, city.Population ciPop,

city.Population / country.Population * 100Scale

FROM country, city

WHERE Capital = ID

这样的查询叙述就会比较长一些,也比较容易打错;所以在结合查询的叙述中,通常为帮「FROM」子句后面的表格都取一个「表格别名」:

image.png

使用表格别名以后:

image.png

帮「FROM」子句中使用到的表格都取一个表格别名,这样的查询叙述通常也可以比较简短一些了。


2.4 使用「INNER JOIN」

执行结合查询除了使用上列讨论的方式外,还有另外一种结合查询语法:

image.png

虽然这两种写法看起来的差异很大,不过它们的想法会是一样的。首先是需要查询的栏位:

image.png

接下来是需要用到的表格,不过你要使用「INNER JOIN」把两个表格「结合」起来:

image.png

最后是结合条件:

image.png

上列使用「INNER JOIN」的结合查询执行以后,跟之前使用结合条件的结合查询,所得到的结果是完全一样的。所以查询「国家和首都的人口和比例」的结合查询,也可以改用下列的写法:

SELECT a.name, a.Population coPop,

b.Name, b.Population ciPop,

b.Population / a.Population * 100

FROM country a INNERJOIN city b ON Capital = ID

使用「INNER JOIN」的结合查询还有另外一种选择:

image.png

下列是使用「ON」或是「USING」来设定结合条件的情况:

image.png

所以如果想要查询「cmdev」资料库中,员工资料和他们的部门名称,就会有三种写法可以选择了:

image.png

3 Outer Join

在「cmdev」的员工资料(emp)表格中,部门编号(deptno)栏位是用来储存员工所属的部门用的;不过有一些员工并没有部门编号:

image.png

所以如果你使用「内部结合」的作法执行下列的查询,你会发现少了两个员工的资料:

image.png

这是因为使用「内部结合」的查询,一定要符合「结合条件」的资料才会出现:

image.png

如果你想查询的资料是「包含部门名称的员工资料,可是没有分派部门的员工就不用出现了」,那使用「内部结合」就可以完成你的工作了;可是如果你想要查询的资料是「包含部门名称的员工资料,没有分派部门的员工也要出现」,那你就要使用「OUTER JOIN」,这种结合查询通常称为「外部结合」:

image.png

除了多一个「LEFT」或「RIGHT」,还有把「INNER」换成「OUTER」外,其它的部份与内部结合的作法都是一样的。


3.1 LEFT OUTER JOIN

所以在结合查询的应用中,如果你想要查询的资料是「包含部门名称的员工资料,没有分派部门的员工也要出现」,也就是希望不符合结合条件的资料也要出现的话,就要换成使用「LEFT OUTER JOIN」来执行结合查询。OUTER JOIN分为LEFT和RIGHT两种,在这个范例中,要使用LEFT才符合查询的需求:

image.png


3.2 RIGHT OUTER JOIN

其实使用「LEFT OUTER JOIN」或是「RIGHT OUTER JOIN」并没有差异,以上列的需求来说,要查询「包含部门名称的员工资料,没有分派部门的员工也要出现」,就是要以「cmdev.emp」表格的资料为主,所以下列两种写法所得到的结果是完全一样的:

image.png

了解两种「OUTER JOIN」的后,下列这两个看起来会有点混淆的查询,虽然只有「LEFT」与「RIGHT」的差异,它们所完成的查询需求,却是完全不一样的:

image.png

所以使用「RIGHT OUTER JOIN」的查询需求,就成为「部门名称与该部门的员工资料,没有员工的部门也要出现」:

image.png


4 合并查询

在关联式资料库中,因为表格的设计,你常会使用结合查询来取得需要的资料,结合查询指的是在「一个」查询叙述中使用「多个」资料表。而现在要讨论的「合并、UNION」查询,指的是把一个以上的查询叙述所得到的结果合并为一个,有这样的需求时,你会在多个查询叙述之间使用「UNION」关键字:

image.png

以下列这两个独立的查询来说,它们在执行以后会得到各自传回查询的纪录:

image.png

如果使用「UNION」关键字把这两个查询合并起来的话,就只会得到一个查询结果,不过这个查询结果会包含两个查询所得到的纪录:

image.png

在执行合并查询的时候,有一些规则要知道与遵守。第一个规则是回传结果的栏位名称:

image.png

第二个规则是所有查询叙述的栏位数量一定要一样:

image.png

上列的范例比较看不出为什么要使用合并查询,一般来说,你大概会因为下列的原因,把原来的查询叙改用合并查询的写法来完成你的需求:

image.png


相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
MySQL数据库入门学习
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。   相关的阿里云产品:云数据库RDS MySQL 版 阿里云关系型数据库RDS(Relational Database Service)是一种稳定可靠、可弹性伸缩的在线数据库服务,提供容灾、备份、恢复、迁移等方面的全套解决方案,彻底解决数据库运维的烦恼。 了解产品详情: https://www.aliyun.com/product/rds/mysql 
相关文章
|
3月前
|
SQL 缓存 监控
MySQL缓存机制:查询缓存与缓冲池优化
MySQL缓存机制是提升数据库性能的关键。本文深入解析了MySQL的缓存体系,包括已弃用的查询缓存和核心的InnoDB缓冲池,帮助理解缓存优化原理。通过合理配置,可显著提升数据库性能,甚至达到10倍以上的效果。
|
3月前
|
SQL 关系型数据库 MySQL
MySQL的查询操作语法要点
储存过程(Stored Procedures) 和 函数(Functions) : 储存过程和函数允许用户编写 SQL 脚本执行复杂任务.
245 14
|
3月前
|
SQL 关系型数据库 MySQL
MySQL的查询操作语法要点
以上概述了MySQL 中常见且重要 的几种 SQL 查询及其相关概念 这些知识点对任何希望有效利用 MySQL 进行数据库管理工作者都至关重要
126 15
|
3月前
|
SQL 监控 关系型数据库
SQL优化技巧:让MySQL查询快人一步
本文深入解析了MySQL查询优化的核心技巧,涵盖索引设计、查询重写、分页优化、批量操作、数据类型优化及性能监控等方面,帮助开发者显著提升数据库性能,解决慢查询问题,适用于高并发与大数据场景。
|
3月前
|
SQL 监控 关系型数据库
MySQL高级查询技巧:子查询、联接与集合操作
本文深入解析了MySQL高级查询的核心技术,包括子查询、联接和集合操作,通过实际业务场景展示了其语法、性能差异和适用场景,并提供大量可复用的代码示例,助你从SQL新手进阶为数据操作高手。
|
3月前
|
缓存 关系型数据库 BI
使用MYSQL Report分析数据库性能(下)
使用MYSQL Report分析数据库性能
162 3
|
3月前
|
关系型数据库 MySQL 数据库
自建数据库如何迁移至RDS MySQL实例
数据库迁移是一项复杂且耗时的工程,需考虑数据安全、完整性及业务中断影响。使用阿里云数据传输服务DTS,可快速、平滑完成迁移任务,将应用停机时间降至分钟级。您还可通过全量备份自建数据库并恢复至RDS MySQL实例,实现间接迁移上云。
|
3月前
|
关系型数据库 MySQL 数据库
阿里云数据库RDS费用价格:MySQL、SQL Server、PostgreSQL和MariaDB引擎收费标准
阿里云RDS数据库支持MySQL、SQL Server、PostgreSQL、MariaDB,多种引擎优惠上线!MySQL倚天版88元/年,SQL Server 2核4G仅299元/年,PostgreSQL 227元/年起。高可用、可弹性伸缩,安全稳定。详情见官网活动页。
800 152
|
4月前
|
存储 运维 关系型数据库
从MySQL到云数据库,数据库迁移真的有必要吗?
本文探讨了企业在业务增长背景下,是否应从 MySQL 迁移至云数据库的决策问题。分析了 MySQL 的优势与瓶颈,对比了云数据库在存储计算分离、自动化运维、多负载支持等方面的优势,并提出判断迁移必要性的五个关键问题及实施路径,帮助企业理性决策并落地迁移方案。
|
3月前
|
关系型数据库 MySQL 分布式数据库
阿里云PolarDB云原生数据库收费价格:MySQL和PostgreSQL详细介绍
阿里云PolarDB兼容MySQL、PostgreSQL及Oracle语法,支持集中式与分布式架构。标准版2核4G年费1116元起,企业版最高性能达4核16G,支持HTAP与多级高可用,广泛应用于金融、政务、互联网等领域,TCO成本降低50%。

推荐镜像

更多