楼主:心都让你吓出来了!html
狮王:淡定,打个小喷嚏而已mysql
神奇的 SQL 之 联表细节 → MySQL JOIN 的执行过程(一)中,咱们讲到了 3 种联表算法:SNL、BNL 和 INL,了解了数据的查询方式是 one by one,联表方式也是 one by one ;并谈到了 ON 和 WHERE,对下图中所说的提出了质疑算法
认为 ON 和 WHERE 的生效时机有待商榷;此时楼主开始了欠你们的帐sql
神奇的 SQL 之 联表细节 → MySQL JOIN 的执行过程(二)中对联表算法进行了补充,详细介绍了 MRR 和 BKA,但仍是未介绍 ON 和 WHERE,楼主依旧欠着你们的帐,心里涌满了愧疚ide
终于在今天,楼主痛定思痛,决定将这笔帐还上;此刻楼主的心里独白是这样的oop
此时各位看官的心里确定嘀咕着:你特么欠帐欠的这么义愤填膺 ? 不过我好喜欢post
咳咳,闲话很少说,进入咱们今天的正题spa
SQL 的执行顺序相信你们多少有所了解,上网一搜也很快就能找到答案3d
除了 WITH 用的比较少以外,其余都比较经常使用,相信你们对上面的执行顺序也没有什么疑问;咱们重点关注下 JOIN、ON 和 WHEREcode
那么 WHERE 是否是必定是在 ON 以后生效了 ? 咱们带着这个疑问往下看
on 针对的关联条件,是表与表之间经过哪些列、以什么条件进行关联,而 where 针对的是过滤条件;二者从概念上来说是不一样的
另外 on 必定是与 join 一并使用的,join 会添加外部行,并将外部行中被驱动表的字段填充 null ,而 where 进行过滤的时候,只有逻辑判断为 true 的记录才会保留,逻辑值为 false 和 unknown 的记录都会过滤掉(更多详情:神奇的 SQL 之温柔的陷阱 → 三值逻辑 与 NULL !);二者获得的结果会有所不一样
上面说的可能有些抽象,咱们结合具体示例来看;MySQL 版本 5.7.21 ,准备表和初始数据
create table tbl_a (a int primary key, b int, c int, d int, e varchar(50)); insert into tbl_a values (4,3,1,1,'a'); insert into tbl_a values (1,1,1,2,'d'); insert into tbl_a values (8,8,7,8,'h'); insert into tbl_a values (2,2,1,2,'g'); insert into tbl_a values (5,2,2,5,'e'); insert into tbl_a values (3,3,2,1,'c'); insert into tbl_a values (7,4,0,5,'b'); insert into tbl_a values (6,5,2,4,'f'); create table tbl_b like tbl_a; insert into tbl_b SELECT * from tbl_a; insert into tbl_a values (9,9,9,9,'9'); insert into tbl_b values (10,10,10,10,'10');
咱们先来看看 left join(right join相似)
SELECT * FROM tbl_a a LEFT JOIN tbl_b b ON a.a = b.a AND a.b = b.b; /*query_on*/ SELECT * FROM tbl_a a LEFT JOIN tbl_b b ON a.a = b.a WHERE a.b = b.b; /*query_where*/
咱们能够看到:
语句 query_on 返回了 tbl_a 中的所有记录,tbl_b 无对应记录的字段值填成 NULL,这是由于 join 会添加外部行,将 tbl_a 有而 tbl_b 中没有的记录添加到结果集
语句 query_where 返回的是 8 行。由于最后的一行,在表 tbl_b 中没有匹配的字段,因此 where 后的 b.b 的值是 NULL,而 a.b 的值是 9,那么 where 9 = NULL 的结果是 unknown 而不是 true,所以这条记录不能做为结果集的一部分
咱们再来看看 inner join
SELECT * FROM tbl_a a INNER JOIN tbl_b b ON a.a = b.a AND a.b = b.b; /*query_on*/ SELECT * FROM tbl_a a INNER JOIN tbl_b b ON a.a = b.a WHERE a.b = b.b; /*query_where*/
咱们能够看到,执行结果是同样的,inner join 查询的就是驱动表与被驱动表同时存在的记录,因此过滤条件无论放在 ON 里,仍是放在 WHERE 里,执行结果是同样的
ON 后的关联条件与 WHERE 后的过滤条件,这二者的执行顺序是否如 SQL 执行顺序图中说的那样,ON 必定先与 WHERE ?
问题先放着,咱们以 left join 为例,来看看 4 个案例,也许从中能找到咱们想要的答案
恰好上面的 tbl_a 和 tbl_b 知足条件,咱们来看看 SQL 的执行计划
EXPLAIN SELECT * FROM tbl_a a LEFT JOIN tbl_b b ON a.b = b.b AND a.c = b.c WHERE a.b >= 2 AND a.b < 10 AND a.c > 0 AND a.d != 1 AND a.e != 'a'
驱动表是 tbl_a,这个相信你们没问题,咱们重点看下 type 和 Extra
type:上面的 ALL 表示全表扫描 a 表,下面的 ALL 表示全表关联,a 表中每一条知足条件的记录都会与 b 表中所有 9 条记录逐条进行关联
Extra:Using where 表示要进行 WHERE 条件过滤,Using join buffer (Block Nested Loop) 表示用到了 BNL
这条 SQL 的执行流程应该是这样的:
此时你们看出什么了没 ? ON 后的关联条件是在 WHERE 后的过滤条件以前生效的吗 ?
这个案例不太常见,由于表没有二级索引,咱们接着往下看看有二级索引的状况
咱们在 tbl_a 建一个组合索引 create index idx_bcd on tbl_a(b, c, d); ,而后往 tbl_a 和 tbl_b 中各插入 10W 条记录,咱们再来看执行计划
上图中红框标记的字段重点关注下,不知道字段含义的小伙伴,能够去翻翻我以前关于 explain的博客
那么此时 SQL 的执行流程应该是这样的:
就步骤 1 与 示例 1 中的步骤 1 不一样,其他 2 步是同样的
此时 WHERE 后的过滤条件的生效时机也是早于 ON 后的关联条件的
将 tbl_b 做为左表,tbl_a 做为右表,咱们来看效果
此时 SQL 的执行流程应该是这样的:
此时 ON 后的关联条件的生效时机是早于 WHERE 后的过滤条件的
咱们在 tbl_b 表上建一个组合索引 create index idx_bcd on tbl_b(b, c, d); 咱们来看看 SQL 的执行计划
此时 SQL 的执行流程应该是这样的:
先是 WHERE 中的 Index Filter 条件生效,而后是 ON 后的关联条件生效,最后是 WHERE 中的 Table Filter 生效,关联条件的生效时间穿插在过滤条件的生效时间中
自此,关于 ON 和 WHERE 的生效时机,你清楚了吗 ?
一、关联博客
若是没有读楼主的前几篇博客,那么有些概念可能不理解,楼主把相关联的博客都列一下
神奇的 SQL 之温柔的陷阱 → 三值逻辑 与 NULL !
神奇的 SQL 之 MySQL 执行计划 → EXPLAIN,让咱们了解 SQL 的执行过程!
神奇的 SQL 之 联表细节 → MySQL JOIN 的执行过程(一)
神奇的 SQL 之 联表细节 → MySQL JOIN 的执行过程(二)
对相关概念不了解的能够去对应的博客查阅
二、ON 和 WHERE
二者好区分,也容易混淆,他们在概念上就作了明确区分,可是又能够作概念以外的事,因此用着用着就开始混淆了
楼主推荐:严格按他们的概念来处理,ON 后跟关联条件,其余的都放到 WHERE 后作过滤条件;尽可能保证 SQL 语义清晰
至于他两的生效时机,须要结合表结构,以及具体的 SQL 来分析,而不是 ON 必定先于 WHERE