前言

这里 我们主要是 看一下 having 的相关实现 

having 经常是配合 group by 这边进行使用, 进行一个基于 group by 之后的结果的一个, 条件限定

我们这里 以最简单的 group by + having 来进行调试, 他会分为 两个阶段, 一个阶段是 group by 之后的结果输出到临时表, 另外一个阶段是基于这个临时表的一个 条件查询

然后 我们之后再来看一下 它的这边查询的一个 转换

 

 

测试用例

测试数据表如下 

CREATE TABLE `tz_test` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `field1` varchar(128) DEFAULT NULL,
  `field2` varchar(128) DEFAULT NULL,
  PRIMARY KEY (`id`) USING BTREE,
  UNIQUE KEY `field_1_2` (`field1`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=18 DEFAULT CHARSET=utf8

 

测试数据如下 

 

测试 sql 以及执行结果如下 

 

 

group by 的查询

这是 group by 的迭代的处理 

这里是第一条记录, field2 为 1, 目前的 count(*) 为 1, 然后 写入数据到 临时表  

 

数据写出到 临时表 “/tmp/#sql_16fb4_0”

 

然后接着 会向该临时文件添加 (2, 1), (3, 1) , (4, 1) , (5, 1) , (6, 1) , (7, 1) , (8, 1) , (9, 1) , (10, 1)

 

然后最后一条记录, field2 为 1 的记录已经存在, 为 (1, 1), 这里会进行 merge, 将新的 (1, 2) 替换掉原来的 (1, 1)

 

 

having 条件的过滤

having 的过滤是在 基于 group by 的临时表进行的过滤 

 

然后 后面的比较如下, 右值为 我们输入的常量 2, 左值为我们临时表的 keyField 值为 count(*)

 

然后 外层就是遍历临时表的核心处理

如果不满足 having 的条济, 则跳过, 否则 写出到临时文件 执行下一个阶段的处理

 

 

having 条件查询更新为子查询

假设我们将 上面查询更新为如下子查询, 我们来调试一下 这个过程

select * from (
select field2, count(*) as count from tz_test group by field2
) as tmp 
where tmp.count = 2;

 

这个过程会比 上面的直接 group by + having 会更加复杂一些 

这里是 group by 之后的结果输出到一个临时表 “/tmp/#sql16fb4_1”

 

然后外层是查询 tz_test 做 group by 之后将数据输出到临时表 “/tmp/#sql16fb4_1”

 

 

然后更外层是我们的 tmp 临时表, 它的数据来源是临时表 “/tmp/#sql16fb4_1”

 

整体数据传输流程如下 

tz_test 做 group by 之后将结果输出到临时表 “/tmp/#sql16fb4_1” 的流程 

 

临时表 “/tmp/#sql16fb4_1” 传输到 临时表tmp 的过程, 可以看到源表为 临时表 “/tmp/#sql16fb4_1”

 

目标表为 临时表tmp 

 

然后查询的时候 field2 上面创建了索引, 直接根据 索引进行查询

然后这里的 索引查询的过程中就已经执行了 “where tmp.count = 2;” 的逻辑处理了 

 

 

综上 转换为了子查询之后, 多了一步 数据的从临时表 到 临时表tmp 的传输

但是 临时表tmp 这边的查询 在一定的条件下增加了索引

 

 

完