前言
这里 我们主要是 看一下 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 这边的查询 在一定的条件下增加了索引
完
