-
LEFT JOIN子查询
2011-09-26 17:29:502:LEFT JOIN ON子查询 LEFT JOIN(SELECT * FROM mobileuser ORDER BY id DESC)AS m ON 如果右边表符合条件的记录有两个,则取ID最大的那个 3:GROUP_CONCAT(d.lessonName)......GROUP BY d.mac根据d.mac进行...SELECT m.phoneNumber,m.course,m.source,m.mobileArea,m.age,m.sex,m.regTime,d.mac, GROUP_CONCAT(d.lessonName) AS lname FROM downloadrecord d LEFT JOIN(SELECT * FROM mobileuser ORDER BY id DESC)AS m ON d.mac=m.mac AND d.mac='8C-7B-9D-F0-6A-3D' GROUP BY d.mac
1:LEFT JOIN ON 左连接,将左边表所有记录全部列出,如果右边表对应的记录有值则将记录值列举出来 2:LEFT JOIN ON子查询
如果右边表符合条件的记录有两个,则取ID最大的那个LEFT JOIN(SELECT * FROM mobileuser ORDER BY id DESC)AS m ON
3:GROUP_CONCAT(d.lessonName)......GROUP BY d.mac根据d.mac进行组合查询,同事对lessonName字段进行连接显示为一个字段lname
-
mysql left join子查询条数_MySQL加入后限制LEFT JOIN子查询
2021-01-27 16:20:46目前我有这个查询:SELECT post.id AS postID, sCom.id as CommentID FROM `post` LEFT JOIN (SELECT * FROM `comment` LIMIT 5) AS sCom ON sCom.post_id = post.id;输出:postID | CommentID1 | 12 | null3 | n...目前我有这个查询:
SELECT post.id AS postID, sCom.id as CommentID FROM `post` LEFT JOIN (SELECT * FROM `comment` LIMIT 5) AS sCom ON sCom.post_id = post.id;
输出:
postID | CommentID
1 | 1
2 | null
3 | null
4 | 2
5 | 3
5 | 4
5 | 5
它有效,但它在JOINing之前限制了注释表.结果是,它选择前5个注释并映射它. ID为5的所有注释都将被忽略.
如何重写查询以选择最多5条评论的帖子?
当前表结构:
发布:
CREATE TABLE IF NOT EXISTS `post` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`feed_id` int(11) DEFAULT NULL,
`user_id` int(11) DEFAULT NULL,
`origin_id` int(11) DEFAULT NULL,
`content` longtext COLLATE utf8_unicode_ci NOT NULL,
`enabled` tinyint(1) NOT NULL,
`created_at` datetime NOT NULL,
`updated_at` datetime NOT NULL,
PRIMARY KEY (`id`),
KEY `IDX_5A8A6C8D51A5BC03` (`feed_id`),
KEY `IDX_5A8A6C8DA76ED395` (`user_id`),
KEY `IDX_5A8A6C8D56A273CC` (`origin_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=6 ;
评论:
CREATE TABLE IF NOT EXISTS `comment` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`feed_id` int(11) DEFAULT NULL,
`user_id` int(11) DEFAULT NULL,
`post_id` int(11) DEFAULT NULL,
`content` longtext COLLATE utf8_unicode_ci NOT NULL,
`enabled` tinyint(1) NOT NULL,
`created_at` datetime NOT NULL,
`updated_at` datetime NOT NULL,
PRIMARY KEY (`id`),
KEY `IDX_9474526C51A5BC03` (`feed_id`),
KEY `IDX_9474526CA76ED395` (`user_id`),
KEY `IDX_9474526C4B89032C` (`post_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=11 ;
谢谢
-
left join 子查询_SQL 子查询的优化
2020-12-03 15:16:47子查询(Subquery)的优化一直以来都是 SQL 查询优化中的难点之一。关联子查询的基本执行方式类似于 Nested-Loop,但是这种执行方式的效率常常低到难以忍受。当数据量稍大时,必须在优化器中对其进行去关联化...子查询(Subquery)的优化一直以来都是 SQL 查询优化中的难点之一。关联子查询的基本执行方式类似于 Nested-Loop,但是这种执行方式的效率常常低到难以忍受。当数据量稍大时,必须在优化器中对其进行去关联化(Decoorelation 或 Unnesting),将其改写为类似于 Semi-Join 这样的更高效的算子。
前人已经总结出一套完整的方法论,理论上能对任意一个查询进行去关联化。本文结合 SQL Server 以及 HyPer 的几篇经典论文,由浅入深地讲解一下这套去关联化的理论体系。它们二者所用的方法大同小异,基本思想是想通的。
本文的例子都基于 TPC-H 的表结构,这里 有一份供你参考。
子查询简介
子查询是定义在 SQL 标准中一种语法,它可以出现在 SQL 的几乎任何地方,包括 SELECT, FROM, WHERE 等子句中。
总的来说,子查询可以分为关联子查询(Correlated Subquery)和非关联子查询(Non-correlated Subquery)。后者非关联子查询是个很简单的问题,最简单地,只要先执行它、得到结果集并物化,再执行外层查询即可。下面是一个例子:
SELECT c_count, count(*) AS custdist FROM ( SELECT c_custkey, count(o_orderkey) AS c_count FROM CUSTOMER LEFT OUTER JOIN ORDERS ON c_custkey = o_custkey AND o_comment NOT LIKE '%pending%deposits%' GROUP BY c_custkey ) c_orders GROUP BY c_count ORDER BY custdist DESC, c_count DESC;
▲ TPCH-13 是一个非关联子查询
非关联子查询不在本文讨论范围之列,除非特别声明,以下我们说的子查询都是指关联子查询。
关联子查询的特别之处在于,其本身是不完整的:它的闭包中包含一些外层查询提供的参数。显然,只有知道这些参数才能运行该查询,所以我们不能像对待非关联子查询那样。
根据产生的数据来分类,子查询可以分成以下几种:
标量(Scalar-valued)子查询:输出一个只有一行一列的结果表,这个标量值就是它的结果。如果结果为空(0 行),则输出一个 NULL。但是注意,超过 1 行结果是不被允许的,会产生一个运行时异常。
标量子查询可以出现在任意包含标量的地方,例如 SELECT、WHERE 等子句里。下面是一个例子:
SELECT c_custkey FROM CUSTOMER WHERE 1000000 < ( SELECT SUM(o_totalprice) FROM ORDERS WHERE o_custkey = c_custkey -- Correlated! )
▲ Query 1: 一个出现在 WHERE 子句中的标量子查询
SELECT o_orderkey, ( SELECT c_name FROM CUSTOMER WHERE c_custkey = o_custkey -- Correlated! ) AS c_name FROM ORDERS
▲ Query 2: 一个出现在 SELECT 子句中的标量子查询
存在性检测(Existential Test)子查询:特指 EXISTS 的子查询,返回一个布尔值。如果出现在 WHERE 中,这就是我们熟悉的 Semi-Join。当然,它可能出现在任何可以放布尔值的地方。
SELECT c_custkey FROM CUSTOMER WHERE c_nationkey = 86 AND EXISTS( SELECT * FROM ORDERS WHERE o_custkey = c_custkey -- Correlated! )
▲ Query 3: 一个 Semi-Join 的例子
集合比较(Quantified Comparision)子查询:特指 IN、SOME、ANY 的查询,返回一个布尔值,常用的形式有:
x = SOME(Q)
(等价于x IN Q
)或X <> ALL(Q)
(等价于x NOT IN Q
)。同上,它可能出现在任何可以放布尔值的地方。SELECT c_name FROM CUSTOMER WHERE c_nationkey <> ALL (SELECT s_nationkey FROM SUPPLIER)
▲ Query 4: 一个集合比较的非关联子查询
原始执行计划
我们以 Query 1 为例,直观地感受一下,为什么说关联子查询的去关联化是十分必要的。
下面是 Query 1 的未经去关联化的原始查询计划(Relation Tree)。与其他查询计划不一样的是,我们特地画出了表达式树(Expression Tree),可以清晰地看到:子查询是实际上是挂在 Filter 的条件表达式下面的。
实际执行时,查询计划执行器(Executor)在执行到 Filter 时,调用表达式执行器(Evaluator);由于这个条件表达式中包含一个标量子查询,所以 Evaluator 又会调用 Executor 计算标量子查询的结果。
这种 Executor - Evaluator - Executor 的交替调用十分低效!考虑到 Filter 上可能会有上百万行数据经过,如果为每行数据都执行一次子查询,那查询执行的总时长显然是不可接受的。
Apply 算子
上文说到的 Relation - Expression - Relation 这种交替引用不仅执行性能堪忧,而且,对于优化器也是个麻烦的存在——我们的优化规则都是在匹配并且对 Relation 进行变换,而这里的子查询却藏在 Expression 里,令人无从下手。
为此,在开始去关联化之前,我们引入 Apply 算子:
Apply 算子(也称作 Correlated Join)接收两个关系树的输入,与一般 Join 不同的是,Apply 的 Inner 输入(图中是右子树)是一个带有参数的关系树。
Apply 的含义用下图右半部分的集合表达式定义:对于 Outer Relation
中的每一条数据
,计算 Inner Relation
,输出它们连接(Join)起来的结果
。Apply 的结果是所有这些结果的并集(本文中说的并集指的是 Bag 语义下的并集,也就是 UNION ALL)。
Apply 是 SQL Server 的命名,它在 HyPer 的文章中叫做 Correlated Join。它们是完全等价的。考虑到 SQL Server 的文章发表更早、影响更广,本文中都沿用它的命名。
根据连接方式(
)的不同,Apply 又有 4 种形式:
- Cross Apply
:这是最基本的形式,行为刚刚我们已经描述过了;
- Left Outer Apply
:即使
为空,也生成一个
。
- Semi Apply
:如果
不为空则返回
,否则丢弃;
- Anti-Semi Apply
:如果
为空则返回
,否则丢弃;
我们用刚刚定义的 Apply 算子来改写之前的例子:把子查询从 Expression 内部提取出来。结果如下:
上面的例子中,我们可以肯定 Scalar Agg 子查询有且只有一行结果,所以可以直接转成 Apply。但某些情况下,可能无法肯定子查询一定能返回 0 或 1 行结果(例如,想象一下 Query 2 如果 c_custkey 不是唯一的),为了确保 SQL 语义,还要在 Apply 右边加一个
算子:
理论上,我们可以将所有的子查询转换成 Apply 算子,一个通用的方法如下:
- 如果某个算子的表达式中出现了子查询,我们就把这个子查询提取到该算子下面(留下一个子查询的结果变量),构成一个
算子。如果不止一个子查询,则会产生多个
。必要的时候加上
算子。
- 然后应用其他一些规则,将
转换成
、
、
。例如上面例子中的子查询结果
被用作 Filter 的过滤条件,NULL 值会被过滤掉,因此可以安全地转换成
。
下面这个例子中,Filter 条件表达式中包含
、
两个子查询。转换之后分别生成了对应的 Apply 算子。其中
无法确定只会生成恰好一条记录,所以还加上了
算子。
基本消除规则
第一组规则是最基本的规则,等式中的
说明它不限制连接类型,可以是
中的任意一个。
这两条规则是非常显而易见的,翻译成大白话就是:如果 Apply 的右边不包含来自左边的参数,那它就和直接 Join 是等价的。
下面是对 Query 3 应用规则 (2) 的例子:
Project 和 Filter 的去关联化
第二组规则描述了如何处理子查询中的 Project 和 Filter,其思想可以用一句话来描述:尽可能把 Apply 往下推、把 Apply 下面的算子向上提。
注意这些规则仅处理 Cross Apply 这一种情况。其他 3 种 Apply 的变体,理论上都可以转换成 Cross Apply,暂时我们只要知道这个事实就可以了。
你可能会问:通常我们都是尽可能把 Filter、Project 往下推,为什么这里会反其道而行呢?关键在于:Filter、Project 里面原本包含了带有关联变量的表达式,但是把它提到 Apply 上方之后,关联变量就变成普通变量了!这正是我们想要的。
我们稍后就会看到这样做的巨大收益:当 Apply 被推最下面时,就可以应用第一组规则,直接把 Apply 变成 Join,也就完成了子查询去关联化的优化过程。
下面是对 Query 2 应用规则 (3) 的例子。之后再应用规则 (1),就完成了去关联化过程。
Aggregate 的去关联化
第三组规则描述如何处理子查询中的 Aggregate(即 Group By)。和上一组一样,我们的指导思想仍然是:尽可能把 Apply 往下推、把 Apply 下面的算子向上提。
下面等式中,
表示带有 Group By 分组的聚合(Group Agg),其中
表示分组的列,
表示聚合函数的列;
表示不带有分组的聚合(Scalar Agg)。
这一组规则不像之前那么简单直白,我们先看一个例子找找感觉。下面是对 Query 1 运用规则 (9) 的结果:
规则 (9) 在下推 Apply 的同时,还将 ScalarAgg 变成了 GroupAgg,其中,分组列就是 R 的 key,在这里也就是 CUSTOMER 的主键 c_custkey。
如果 R 没有主键或唯一键,理论上,我们可以在 Scan 时生成一个。
为什么变换前后是等价的呢?变换前,我们是给每个 R 的行做了一次 ScalarAgg 聚合计算,然后再把聚合的结果合并起来;变换后,我们先是将所有要聚合的数据准备好(这被称为 augment),然后使用 GroupAgg 一次性地做完所有聚合。
这也解释了为什么我们要用
而不是原本的
:原来的 ScalarAgg 上,即使输入是空集,也会输出一个 NULL。如果我们这里用
,恰好也会得到一样的行为(*);反之,如果用
就有问题了——没有对应 ORDERS 的客户在结果中消失了!
规则 (8) 处理的是 GroupAgg,道理也是一样的,只不过原来的分组列也要留着。
ScalarAgg 转换中的细节*
细心的读者可能注意到,规则 (9) 右边产生的聚合函数是
,多了一个单引号,这暗示它和原来的聚合函数
可能是有些不同的。那什么情况下会不同呢?这个话题比较深入了,不感兴趣的同学可以跳过。
首先我们思考下,GroupAgg 以及
的行为真的和变换前一模一样吗?其实不然。举个反例:
SELECT c_custkey, ( SELECT COUNT(*) FROM ORDERS WHERE o_custkey = c_custkey ) AS count_orders FROM CUSTOMER
设想一下:客户 Eric 没有任何订单,那么这个查询应当返回一个
['Eric', 0]
的行。但是,当我们应用了规则 (9) 做变换之后,却得到了一个['Eric', 1]
的值,结果出错了!为何会这样呢?变换之后,我们是先用 LeftOuterJoin 准备好中间数据(augment),然后用 GroupAgg 做聚合。LeftOuterJoin 为客户 Eric 生成了一个
['Eric', NULL, NULL, ...]
的行;之后的 GroupAgg 中,聚合函数COUNT(*)
认为 Eric 这个分组有 1 行数据,所以输出了['Eric', 1]
。下面是个更复杂的例子,也有类似的问题:
SELECT c_custkey FROM CUSTOMER WHERE 200000 < ( SELECT MAX(IF_NULL(o_totalprice, 42)) -- o_totalprice may be NULL FROM ORDERS WHERE o_custkey = c_custkey )
作为总结,问题的根源在于:
,这样的聚合函数
都有这个问题。
变换后的 GroupAgg 无法区分它看到的 NULL 数据到底是 OuterJoin 产生的,还是原本就存在的,有时候,这两种情形在变换前的 ScalarAgg 中会产生不同的结果。
幸运的是,SQL 标准中定义的聚合函数
都是 OK 的——它们都满足
,我们只要对
稍加变换就能解决这个问题。
- 对于例子一,将
COUNT(*)
替换成一个对非空列(例如主键)的 Count 即可,例如:COUNT(o_orderkey)
; - 对于例子二,需要把
MIN(IF_NULL(o_totalprice, 42))
分成两步来做:定义中间变量X
,先用 Project 计算X = IF_NULL(o_totalprice, 42)
,再对聚合函数MIN(X)
进行去关联化即可。
集合运算的去关联化
最后一组优化规则用来处理带有 Union(对应
UNION ALL
)、Subtract(对应EXCEPT ALL
) 和 Join 算子的子查询。再强调一遍,我们的指导思想是:尽可能把 Apply 往下推、把 Apply 下面的算子向上提。下面的等式中,
表示按照
的 Key 做自然连接:
。和之前一样,我们假设
存在主键或唯一键,如果没有也可以在 Scan 的时候加上一个。
注意到,这些规则与之前我们见过的规则有个显著的不同:等式右边
出现了两次。这样一来,要么我们把这颗子树拷贝一份,要么做成一个 DAG 的执行计划,总之会麻烦许多。
事实上,这一组规则很少能派上用场。在 [2] 中提到,在 TPC-H 的 Schema 下甚至很难写出一个带有 Union All 的、有意义的子查询。
其他
有几个我认为比较重要的点,用 FAQ 的形式列在下面。
► 是否任意的关联子查询都可以被去关联化?
可以说是这样的,在加上少量限定之后,理论上可以证明:任意的关联子查询都可以被去关联化。
证明方法在 [1]、[3] 中都有提及。以 [1] 中为例,思路大致是:
- 对于任意的查询关系树,首先将关联子查询从表达式中提取出来,用 Apply 算子表示;
- 一步步去掉其中非基本关系算子,首先,通过等价变换去掉 Union 和 Subtract;
- 进一步缩小算子集合,去掉 OuterJoin、
、
、
;
- 最后,去掉所有的
,剩下的关系树仅包含基本的一些关系算子,即完成了去关联化。
另一方面,现实世界中用户使用的子查询大多是比较简单的,本文中描述的这些规则可能已经覆盖到 99% 的场景。虽然理论上任意子查询都可以处理,但是实际上,没有任何一个已知的 DBMS 实现了所有这些变换规则。
► HyPer 和 SQL Server 的做法有什么异同?
HyPer 的理论覆盖了更多的去关联化场景。例如
、
、
这三种算子,[3] 中都给出了相应的等价变换规则。而在 [1] 中仅仅是证明了它可以被规约到可处理的情形(实际上嘛,可想而知,一定是没有处理的)。
另一个细节是,HyPer 中还存在这样一条规则:
其中,
,表示对
的 Distinct Project 结果。直接看等式比较晦涩,看下面的例子就容易理解了:
图中,在做 Apply 之前,先拿到需要 Apply 的列的 Distinct 值集合,拿这些值做 Apply,之后再用普通的 Join 把 Apply 的结果连接上去。
这样做的好处是:如果被 Apply 的数据存在大量重复,则 Distinct Project 之后需要 Apply 的行数大大减少。这样一来,即使之后 Apply 没有被优化掉,迭代执行的代价也会减小不少。
► 本文说的这些变换规则,应该用在 RBO 还是 CBO 中呢?换句话说,去关联化后之后的执行计划一定比去关联化之前更好吗?
答案是,不一定。
直观的看,如果 Apply 的左边数据量比较少(例如,仅有 1 条数据),那直接带入 Apply 的右边计算反而是更好的方式。另一种情况是,右边有合适的索引,这种情况下,多次 Apply 的代价也并非不可接受。
所以把这些规则放进一个 CBO 的优化器是更合适的,优化器根据代价估计选出最优的计划来。甚至,在某些情况下,我们还会自右向左地运用这些等式,做“加关联化”。
这和用 HashJoin 还是 NestedLoopJoin 是同样的道理。事实上,NestedLoopJoin 就是 Apply 的一个特例。如果存在合适的索引,NestedLoopJoin 效率高于 HashJoin 是很常见的事情。
References
- Parameterized Queries and Nesting Equivalencies - C Galindo-Legaria
- Orthogonal Optimization of Subqueries and Aggregation - C Galindo-Legaria, M Joshi
- Unnesting Arbitrary Queries - T Neumann, A Kemper
- The Complete Story of Joins (inHyPer) - T Neumann, V Leis, A Kemper
原文链接:https://ericfu.me/subquery-optimization/版权声明:本文章采用 BY-NC-SA 许可协议。转载请注明出处!
- Cross Apply
-
left join 子查询_MYSQL查询语句
2020-12-03 22:16:44环境:employees表:departments表:查询所有:select * from 表名;查询指定字段:select 字段 from 表名;去重查询:select distinct * from 表名;别名查询:select name as '书名' from t_book;select name '...环境:
employees表:
departments表:查询所有:
select * from 表名;
查询指定字段:
select 字段 from 表名;
去重查询:
select distinct * from 表名;
别名查询:
select name as '书名' from t_book;
select name '书名' from t_book;条件查询:
select 查询列表 from 表面 where 筛选条件;
#搭配条件表达式:> < = != <> >= <= && || ! and or not
#如:查询id值为1的书名
select name from book where id = 1;模糊查询:
#查询书名中包含字符a的书籍信息
select * from book where name like '%a%';
#查询员工编号在100到120之间的员工信息
select * from employees where employee_id between 120 and 100;
#查询员工的工种编号是 IT_PROG、AD_VP、AD_PRES中的一个员工名和工种编号
select * from employees where job_id in( 'IT_PROT' ,'AD_VP','AD_PRES');
#is null 和 is not null
#查询有奖金的员工名
select * from employees where commission_pct is not null;排序查询:
# 语法
select 查询列表
from 表名
【where 筛选条件】
order by 排序的字段或表达式;
#其中:
asc代表的是升序,可以省略
desc代表的是降序
#案例:查询员工信息,要求先按工资降序,再按employee_id升序
select *
from employees
order by salary desc,emp_id asc;分组函数:
#sum 求和、avg 平均值、max 最大值 、min 最小值 、count 计算个数
select sum(salary) from emp;
select avg(salary) from emp;
select min(salary) from emp;
select max(salary) from emp;
select count(*) from emp;分组查询:
select 查询列表
from 表
【where 筛选条件】
group by 分组的字段
【order by 排序的字段】;
特点:
1、和分组函数一同查询的字段必须是group by后出现的字段
2、筛选分为两类:分组前筛选和分组后筛选
针对的表 位置 连接的关键字
分组前筛选 原始表 group by前 where
分组后筛选 group by后的结果集 group by后 having
# 每个工种有奖金的员工的最高工资>6000的工种编号和最高工资,按最高工资升序
SELECT MAX(salary),job_id
FROM employees
WHERE commission_pct IS NOT NULL
GROUP BY job_id
HAVING MAX(salary)>6000
ORDER BY MAX(salary);连接查询:(sql99语法)
select 查询列表
from 表1 别名 【连接类型】
join 表2 别名
on 连接条件
【where 筛选条件】
【group by 分组】
【having 筛选条件】
【order by 排序列表】
#内连接(★):inner
#外连接
左外(★):left 【outer】
右外(★):right 【outer】
全外:full【outer】
#交叉连接:cross
#.查询哪个部门的员工个数>3的部门名和员工个数,并按个数降序(添加排序)
select count(*),dept_name
from emp e
inner join dept d
on e.dept_id = d.dept_id
group by dept_name
having count(*) > 3
order by count(*) desc;
#非等值连接练习:查询工资级别的个数>20的个数,并且按工资级别降序
select count(*),grade_level
from emp e
join job_grades g
on e.salary between g.lowest_sal and g.highest_sal
group by grade_level
having count(*) > 20
order by grade_level desc;
#自连接:查询姓名中包含字符k的员工的名字、上级的名字
select e.last_name,m.last_name
from employees e
join employees m
on e.manager_id = m.manager_id
where e.last_name like '%k%';
#查询哪个部门没有员工
#左外
select d.*,employee_id
from departments d
left outer join employees e
on d.department_id =e.department_id
where e.employee_id is null;
#右外
SELECT d.*,e.employee_id
FROM employees e
RIGHT OUTER JOIN departments d
ON d.`department_id` = e.`department_id`
WHERE e.`employee_id` IS NULL;分页查询:
select 查询列表
from 表
【join type join 表2
on 连接条件
where 筛选条件
group by 分组字段
having 分组后的筛选
order by 排序的字段】
limit 【offset,】size;
offset要显示条目的起始索引(起始索引从0开始)
size 要显示的条目个数
#查询第11条——第25条
select * from employees limit 10,15;
#有奖金的员工信息,并且工资较高的前10名显示出来
select * from employees
where commission_pct is not null
order by salary desc
limit 10;联合查询:
语法:
查询语句1
union
查询语句2
union
...
#查询部门编号>90或邮箱包含a的员工信息
select * from employees where email like '%a%' or department_id >90;
#使用联合:
SELECT * FROM employees WHERE email LIKE '%a%'
UNION
SELECT * FROM employees WHERE department_id>90;子查询:
分类:
按子查询出现的位置:
select后面:
仅仅支持标量子查询
from后面:
支持表子查询
where或having后面:★
标量子查询(单行) √
列子查询 (多行) √
行子查询
exists后面(相关子查询)
表子查询
按结果集的行列数不同:
标量子查询(结果集只有一行一列)
列子查询(结果集只有一列多行)
行子查询(结果集有一行多列)
表子查询(结果集一般为多行多列)#查询最低工资大于50号部门最低工资的部门id和其最低工资
SELECT MIN(salary),department_id
FROM employees
GROUP BY department_id
HAVING MIN(salary)>(
SELECT MIN(salary)
FROM employees
WHERE department_id = 50
);
#查询各部门中工资比本部门平均工资高的员工的员工号, 姓名和工资
SELECT employee_id,last_name,salary,e.department_id
FROM employees e
INNER JOIN (
SELECT AVG(salary) ag,department_id
FROM employees
GROUP BY department_id
) ag_dep
ON e.department_id = ag_dep.department_id
WHERE salary>ag_dep.ag ;
#查询在部门的location_id为1700的部门工作的员工的员工号
SELECT employee_id
FROM employees
WHERE department_id =ANY(
SELECT DISTINCT department_id
FROM departments
WHERE location_id = 1700
);
#查询和姓名中包含字母u的员工在相同部门的员工的员工号和姓名
SELECT last_name,employee_id
FROM employees
WHERE department_id IN(
SELECT DISTINCT department_id
FROM employees
WHERE last_name LIKE '%u%'
);
#查询每个部门的平均工资的工资等级
SELECT ag_dep.*,g.`grade_level`
FROM (
SELECT AVG(salary) ag,department_id
FROM employees
GROUP BY department_id
) ag_dep
INNER JOIN job_grades g
ON ag_dep.ag BETWEEN lowest_sal AND highest_sal;查询流程:
语法:
select 查询列表 ⑦
from 表1 别名 ①
连接类型 join 表2 ②
on 连接条件 ③
where 筛选 ④
group by 分组列表 ⑤
having 筛选 ⑥
order by排序列表 ⑧
limit 起始条目索引,条目数; ⑨ -
mysql left join子查询_mysql – 左连接带有子查询的三个表
2021-01-20 20:09:07Check this fiddle for DB and tablesSELECT p.*FROM Products pLEFT JOIN offertran otON p.prod_id = ot.prod_idLEFT JOIN Offers oON ot.offer_id = (SELECT id FROM OffersWhere dF<=3 AND dt>=3)ORDER B.... -
left join 子查询_SQL—数据查询语言(DQL)
2020-12-03 22:16:37SQL-数据查询语言—DQLDQL语法:select cols #查询并展示的数据(字段,表达式等)from tables #查询的数据来源(表,结果集,视图等)where condition #条件语句group by #分组having #分组之后的条件判断order by #排序... -
left join 子查询_Greenplum查询优化器如何消除外连接揭秘
2020-11-26 12:26:22Greenplum经过多年打磨,以性能卓越,速度快胜任不同类型的查询场景。Greenplum之所以查询跑得块,不仅是因为拥有极致优化的执行引擎和节点间网际传输,更依赖于查询处理的大脑中枢:查询优化器。Greenplum查询优化... -
mysql中多个left join子查询写法以及别名用法
2017-10-30 12:09:06ps:解释下 对于Mysql中的语句,牵扯到左查询时 可以用left join关联 但一般对于不知道什么时候起别名 什么时候用括号的老铁们 真实头疼 所以发个模板 剩下的根据自己的业务具体实施。 -
在LEFT JOIN子查询中显示COUNT个?
2011-08-30 18:48:42LEFT JOIN orders_total as ot ON o.orders_id = ot.orders_id WHERE date_purchased between '2011-07-30' AND '2011-08-30 23:59:59' AND ot.class = 'ot_total' AND o.customer_service_id = '' OR o.... -
记一次mysql优化 not in, not exits, left join 子查询
2019-08-24 14:09:34在某次业务逻辑中写到如下逻辑:查询学校级别的未拦截弹窗记录。而弹窗设备表(t_block_blacklist_device)有四种类型(1:学校级黑名单 2:设备级别黑名单 3:略 4:学校级白名单 注:从来没有被加入黑名单或白名单不... -
left join 和子查询效率_SQL总结连接查询
2020-12-01 19:34:57有哪些连接查询连接查询包括外连接:LEFT JOIN、RIGHT JOIN、FULL JOIN,以及内连接:INNER JOIN。本文重点总结LEFT JOIN,其他连接查询不一一举例。| 二 . 左连接LEFT JOIN1)原理:LEFT JOIN返回左表的全部行和右... -
关于Mysql left join和子查询
2018-09-21 12:03:34今天在做一个项目的时候需要关联查询,但是好奇想知道left join 和子查询哪一个比较合适。 于是做了个实验。 子查询: SELECT a.*,(select content from yxhy_news_content where yxhy_news_content.id=a.id... -
mysql 子查询 left join_MySQL left join 与 sub query 子查询是否有区别
2021-01-19 02:55:28sqlexplainSELECT `info_info`.*, `a`.`name` AS `d1name`FROM `info_info`LEFT JOIN (SELECT * FROM `common_diqu`) `a` ON a.id=d1 WHERE `status`=1ORDER BY `tid` DESCid select_type table type poss... -
sql查询--比较left join、join和子查询的性能
2020-09-21 16:02:09比较情况1:left join和join的比较 ...上述业务需求即查询A,B,C三个表交集为结果集,这种情形应该join的效率优于left join,因为left join 两表之间不会自动选择小表驱动大表但是inner join 会自动选择。 比 -
子查询与JOIN&LEFT JOIN比较
2019-10-03 20:46:45MySQL从4.1版本开始支持子查询,使用子查询进行SELECT语句嵌套查询,可以一次完成很多逻辑上需要多个步骤才能完成的SQL操作。...优化方式:可以使用JOIN、LEFT JOIN等方式代替子查询,这些方式不... -
left join 和子查询
2015-06-25 15:55:14[code="sql"... (select name from wp_teacher wt inner join wp_teacher_class wts on wt.teacherid = wts.teacherid where wts.classid = kcs.classid and wts.headmaster = 1 limit... -
left join 和子查询效率_子查询是怎么执行的
2020-12-03 04:36:50号外号外,《MySQL是怎样运行的:从根儿上理解MySQL》书籍即将在掘金上架,本文是其中的一个章节的一小丢丢,书中的内容没有经过多少小白测试,有想当早鸟的同学来一起测试的可以联系我,或者加我微信:子查询的基本... -
left join 关联子查询_ThinkPHP 的join关联查询不使用默认的表前缀
2021-01-22 12:18:58关于ThinkPHP 的关联查询,官方文档是这样描述的:ThinkPHP 关联查询上述join函数中需要三个参数,分别是:join要关联的(完整)表名以及别名,支持三种写法:写法1:[ '完整表名或者子查询'=>'别名' ] 写法2:'... -
leftjoin和子查询哪个效率高呢?
2015-05-07 10:47:05select a.*,b.dept_name from user a left join dept b on a.dept_id=b.dept_id 2. select a.*, (select dept_name from dept where dept_id=a.dept_id) dept_name from user a 一般哪个比较好啊? 效率... -
left semi join和join实现子查询性能对比
2020-02-09 19:45:43left semi join和join实现子查询性能对比 left semi join hive从 0.13 版本实现了in/exist自查询,实现方式是通过left semi join,left semi jion具体实现是在右表(子查询)中先对on的关键字做group by ,然后再... -
left join 关联子查询_WHERE子句做关联查询和JOIN的区别
2021-01-21 21:58:02最近一个项目中,频繁出现“select * from A,B where A.col = B.id ”这种写法,貌似也可以达到我们想要的效果,但是通过 where 子句做关联和各种 join 连接查询到底什么区别呢?我们到底该选择哪一种方式呢?下面... -
mysql表连接和子查询效率_mysql left join 与子查询的性能比较 例子
2021-01-19 06:58:50介绍:使用到了employees的两个表,分别是员工表(employees, 30w24数据),部门经理表...要求查询所有非经理的员工数据:左连接select e.* from employees e LEFT JOIN dept_manager d on e.emp_no = d.emp_no wher... -
mysql join、left join、where、子查询区别
2020-07-14 09:05:11mysql中 对多表的查询有两种方式:表连接,子查询 表连接 是对 多张表 做笛卡尔积,生成临时表,消耗内存 子查询分步的单表查询(in, exists) 表连接时 根据 on 后面的条件做关联 生成临时表后 通过where条件再次... -
SQL子查询和 LEFT JOIN 关键字
2019-05-20 17:36:15SQL子查询 语法: sno in (SELECT sno FROM p_test WHERE category =“800米” ) WHERE category=“立定跳远” and sno in (SELECT sno FROM p_test WHERE category =“800米” ) 上述语句的意思就是2个条件,类型是...
-
焦虑日记
-
在 Linux 上构建企业级 DNS 域名解析服务
-
智能体侧系统体质健康智能测试系统体能测试训练系统软件
-
FFmpeg4.3系列之16:WebRTC之小白入门与视频聊天的实战
-
微信useragent java_微信内置浏览器和小程序的 User Agent 区别及判断方法
-
配置git配置git配置git配置git.zip
-
MySQL NDB Cluster 负载均衡和高可用集群
-
SPFD5408A CPT 2.4 inch Application Note_20070706.pdf
-
用微服务spring cloud架构打造物联网云平台
-
【硬核】一线Python程序员实战经验分享(1)
-
java static 变量存在哪_Java中的静态方法和静态变量存储在哪里?
-
linux基础入门和项目实战部署系列课程
-
java ssh文件下载_Java_JavaEE_轻量级(SSH)_Struts2文件下载支持;
-
java ssh乱码_SSH编写程序中文乱码解决
-
java oracle 分区查询_oracle表分区
-
SPFD54124C_Ver0.4_20071004.pdf
-
哈希开放地址法java_哈希表-开放地址法之线性探测代码(JAVA)
-
vue3从0到1-超详细
-
java ssha_帮忙JAVA程序调试
-
oci-arch-oke-atp-源码