sql嵌套查询慢的原因

文章目录

问题

为了查询一个字段,使用了五层嵌套循环,但是花费了约1分钟
但是5个表的数据每个最多只有10条,怎么会这么慢呢?

解决

比如查询语句

SELECT * FROM studet

分析器会先看语句的第一个词,如果它发现第一个词是SELECT关键字的时候,它会跳到FROM关键字,然后通过FROM关键字找到表名并把表装入内存。 内存中有student表

接着是找WHERE关键字,如果找不到则返回到SELECT找字段解析

SELECT * FROM studet WHERE stu_id=1

如果找到WHERE,则分析其中的条件,完成后再回到SELECT分析字段。最后形成一张我们要的虚表。

WHERE关键字后面的是条件表达式。条件表达式计算完成后,会有一个返回值,即非0或0,非0即为真(true),0即为假(false)。同理WHERE后面的条件也有一个返回值,真或假,来确定接下来执不执行SELECT。

这是执行一条sql语句发生的状况,那么如果进入嵌套查询

SELECT * FROM STUDENT WHERE stu_id IN (SELECT * FROM SC WHERE sc_id IN (SELECT * FROM SS))

分析器先找到关键字SELECT,然后跳到FROM关键字将STUDENT表导入内存,并通过指针p1找到第一条记录,
在这里插入图片描述

接着找到WHERE关键字计算它的条件表达式,
如果为真那么把这条记录装到一个虚表当中,p1再指向下一条记录。
如果为假那么p1直接指向下一条记录,而不进行其它操作。一直检索完整个表,并把虚表返回给用户。
在这里插入图片描述

太可怕了,前面的sql查询一小步,仅仅移动一个指针指向后面的下一条数据,就是后面所有查询条件的一大步
在这里插入图片描述

(外面的那个SELECT)到WHERE关键字的时候,又进入了另一个SQL语句中,
分析器先找到表Student并装入内存,一个指针(例如p1)指向Student表中的第一条记录。然后进入WHERE里分析里面的SQL语句,再把SC表装入内存,另一个指针(例如p2)指向SC表中的第一条记录,分析WHERE后面的条件表达式,依次进行分析,最后分析出一个虚表2。

那么可以继续推演,进入了SS表,把SS表放入内存中,继续where条件的判断,层层套娃

如果虚表为空表,虚表2 也就为false,不返回到SELECT,
而内存中student表的p1指向下一条记录,继续让SC表受尽折磨
p1每移动一次,后面所有的查询都会再次重复进行

如果虚表2不为空也就是有记录,那么虚表2 为true,返回到SELECT并把p1指向的记录添加到主SQL语句的虚表1当中。

(这也是为什么嵌套的SQL语句SELECT 后面为一般为的原因,因为它EXISTS返回的只是真或假,字段的名没有意义,用就行,当然用别的也不会错。 )

这里虽然嵌套的SQL语句分析完了,但主SQL语句只执行了一遍,也就是说p1指向Student的第一条记录,p1还要再指向Student表的下一条记录并分析,这样又进入了嵌套中的SQL语句,同上面说的一样分析。当p1也到了Student表的结尾,整个SQL语句结束。返回虚表1这一列。

其对于内存的消耗,与计算量的消耗非常高,复杂度是MxN次查询,
因为每一条数据都要和后面where的一次子查询的查询结果进行比对,1:N
每次查询分析到from的时候都会把表装进一次内存,创建一次临时表,MxN次的存入内存,内存消耗巨大

  • 1
    点赞
  • 8
    收藏
    觉得还不错? 一键收藏
  • 4
    评论
评论 4
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值