背景介绍
最近在写SQL语句时,对选择中还存在是犹豫不决,于是把两种方法的SQL都写出来对比一下执行效率,发现在的查询效率比存在高了很多,于是想当然的认为在的效率比好存在,但本着寻根究底的原则,我想知道这个结论是否适用所有场景,以及为什么会出现这个结果。
网上查了一下相关资料,大体可以归纳为:外部表小,内部表大时,适用存在;外部表大,内部表小时,适用。那我就困惑了,因为我的SQL语句里面,外表只有1 w级别的数据,内表有30 w级别的数据,按网上的说法应该是存在的效率会比在高的,但我的结果刚好相反! !
“没有调查就没有发言权”!于是我开始研究和存在的实际执行过程,从实践的角度出发,在根本上去寻找原因,于是有了这篇博文分享。
实验数据
我的实验数据包括两张表:t_author表和t_poetry表。
对应表的数据量:
t_author表,13355条记录;
t_poetry表,289917条记录。
对应的表结构如下:
CREATE TABLE <代码> t_poetry> <代码> id> <代码> poetry_id <代码>/长整型数字(20)NOT NULL评论“诗词id”,
<代码> poetry_name varchar (200) NOT NULL评论“诗词名称”,
& lt;字体颜色=red><代码> author_id bigint (20) NOT NULL评论的作者id”& lt;/font>
主键(<代码> id> 唯一键<代码> pid_idx (<代码> poetry_id> 关键<代码> aid_idx (<代码> author_id> )引擎=InnoDB AUTO_INCREMENT=291270默认字符集=utf8mb4CREATE TABLE <代码> t_author> <代码> id> <代码> author_id bigint (20) NOT NULL, & lt;/font>
<代码> author_name varchar (32) NOT NULL,
<代码>王朝> <代码> poetry_num int (8) NOT NULL默认' 0 '
主键(<代码> id> & lt;字体颜色=red>唯一键<代码> authorid_idx (<代码> author_id> )引擎=InnoDB AUTO_INCREMENT=13339默认字符集=utf8mb4<>强执行计划分析在执行过程
sql示例:<代码> select * from塔巴塔巴的地方。x(从tabB y>选择x 0);
其执行计划:
(1)执行tabB表的子查询,得到结果集B,可以使用到tabB表的索引y;
(2)执行塔巴表的查询,查询条件是tabA.x在结果集B里面,可以使用、塔巴到表的索引x。<强>存在执行过程
sql示例:<代码>选择从塔巴存在(从tabB y>选择 0);
其执行计划:
(1)先将塔巴表所有记录取到。
(2)逐行针、塔巴对表的记录,去关联tabB表判断tabB表的子查询是否有返回数据,5.5之后的版本使用块嵌套循环(块嵌套循环)。
(3)如果子查询有返回数据,则将塔巴当前记录返回到结果集。
塔巴相当于取全表数据遍历,tabB可以使用到索引。<>强实验过程
实验针对相同结果集的和存在的SQL语句进行分析。
包含在的SQL语句:
从t_author ta author_id在选择
(从t_poetry tp选择author_id tp.poetry_id> 3650),
包含的SQL语存在句:
从t_author ta,存在选择
(select * from t_poetry tp tp.poetry_id> 3650年,tp.author_id=ta.author_id);<强>第一次实验数据情况
t_author表,13355条记录;t_poetry表,子查询筛选结果集poetry_id> 293650年,121条记录;
执行结果
使用存在耗0.94时,使用在耗时0.03 s,
原因分析
对t_poetry表的子查询结果集很小,且两者在t_poetry表都能使用索引,对t_poetry子查询的消耗基本一致。两者区别在于,使时用,t_author表能使用索引:
