精华内容
下载资源
问答
  • 声明:本文摘自...子查询的子语句可以在一条sql语句的FROM,JOIN,和WHERE后面,本文主要针对在WHERE后面使用子查询与表连接查询的性能做出一点分析。对于表连接查询和子查询性能的讨论众说纷纭,普遍...

    声明:本文摘自https://www.cnblogs.com/cdf-opensource-007/p/6540521.html

    子查询就是在一条查询语句中还有其它的查询语句,主查询得到的结果依赖于子查询的结果。

    子查询的子语句可以在一条sql语句的FROM,JOIN,和WHERE后面,本文主要针对在WHERE后面使用子查询与表连接查询的性能做出一点分析。

    对于表连接查询和子查询性能的讨论众说纷纭,普遍认为的是表连接查询的性能要高于子查询。本文将从实验的角度,对这两种查询的性能做出验证,并就实验结果分析两种查询手段的执行流程对性能的影响。

    首先准备两张表

    1,访问日志表mm_log有150829条记录(相关sql文件已放在文章结尾的链接中)。

    d532c2a1c8b4a2087d7ec81d220267dd.png

    2,用户表mm_member有373条记录(相关sql文件已放在文章结尾的链接中)。

    053c56d4e6cb2e1c71288ae57a573e94.png

    现在要求我们根据这两张表查出2017-02-06那天有那些用户登录过系统。

    我们先来看一下使用表连接查询

    48304ba5e6f9fe08f3fa1abda7d326ab.png

    SELECT

    SQL_NO_CACHE mm.*

    FROM

    mm_member mm

    JOIN

    mm_log ml

    ON

    mm.id = ml.member_id

    WHERE

    ml.access_time LIKE '%2017-02-06%'

    GROUP BY

    ml.member_id;

    48304ba5e6f9fe08f3fa1abda7d326ab.png

    这里使用了 SQL_NO_CACHE 是因为要多次执行这条sql语句,并计算出这条sql查询所耗费的平均时间,所以要关掉mysql的查询缓存,防止多次执行从缓存中读取数据。

    mm.*是取GROUP BY ml.member_id分组后的诸多临时表的第一行数据,相关用法及原理请参见我的另一篇博客(http://www.cnblogs.com/cdf-opensource-007/p/6502556.html)

    对这条sql语句执行了10次,查询所耗费的平均时间在0.120s左右。

    查询结果:(一共有5个用户访问过系统)

    01be45a98759d336c521f0a86112f73c.png

    至于以上这条sql的执行流程已经在前几篇博客中描述的很详细了,这里就不再做叙述了。

    下面使用WHERE后使用子查询的方式实现

    SELECT

    SQL_NO_CACHE mm.username

    FROM

    mm_member mm

    WHERE

    mm.id IN(SELECT ml.member_id FROM mm_log ml WHERE ml.access_time LIKE '%2017-02-06%' GROUP BY ml.member_id);

    当我第一次运行这条sql语句的时候,等了十几秒一直没有结果,我以为我的电脑死机,可Navicat显示处理中,最后40多秒的时候才运行出结果,接连运行了好多次在都是41秒左右出结果。

    4be10ab40b64a795aa2e2ead30460bbf.png

    我们看到执行结果同上。那么使用子查询的性能到底低在哪里呢?

    我的第一种推测是子语句:SELECT ml.member_id FROM mm_log ml WHERE ml.access_time LIKE '%2017-02-06%' GROUP BY ml.member_id耗费了大量的查询时间,因为mm_log这张表中有150829条记录。

    把子语句单拿出来运行一下,发现子语句的运行时间也就在0.111s左右。

    SELECT SQL_NO_CACHE member_id FROM mm_log ml WHERE ml.access_time LIKE '%2017-02-06%' GROUP BY ml.member_id;

    这就说明我的第一种推测是不合理的。

    那就分析下在WHERE后使用子查询IN的执行原理:

    1,IN后面跟的子查询语句的执行结果只能有一列是用来和IN前面的主表的字段匹配的,在这里指的是mm.id。

    2,一条带有子查询的sql语句首先执行的是子语句,主表的数据行按照IN前面主表的字段依次跟子查询的结果进行匹配,子查询中结果中有该数据行对应字段的值,则返回true,该行被WHERE筛选出来。没有则返回false,该行不被筛选。

    3,那么按照2的说法,子查询的效率应该也不低啊,子语句的耗时在0.111s左右,而且主表mm_member和子语句的查询结果相匹配的次数,肯定是要少于表连接查询时数据行间匹配的次数的,但实验结果显示使用子查询的性能确实很低。

    所以我有了第二种推测,主表mm_member数据行的每一行在与IN后面子语句的结果相匹配时,子语句都会重新执行一次,也就是说子语句第一次执行时,不会在内存中有缓存。这类似与使用了两个FOR循环嵌套,外层的FOR循环每拿出一个值,内层的FOR循环都要遍历一次。

    那么根据以上的推测,拿主表mm_member的数据行数乘以子语句的执行时间就应该是整个查询的时间。

    mm_member的数据行数:373

    多次执行子语句算出平均时间在:0.111s

    整个查询耗时的理论时间:41.403s

    多次执行整个查询得出实际查询时间的平均值:40.834s

    计算误差:(理论值-实际值)÷理论值 = 1.37%

    误差还是在可以接受的范围内的,可以证明以上的推测。

    根据以上的实验,我们可以得出的结论是,表连接查询的性能是要高于子查询的。

    另外,对于在子查询中使用IN的性能高还是是用EXITS的性能高,有一种普遍的说法是:

    1,在外表大,内表小,外表中有索引的情况下,使用IN。

    2,在外表小,内表大,内表中有索引的情况下,使用EXITS。

    先介绍一下EXITS的用法,刚好本例符合外表小内表大的情况,就以本例介绍一下。看下SQL:

    SELECT

    SQL_NO_CACHE mm.*

    FROM

    mm_member mm

    WHERE

    EXISTS(SELECT * FROM mm_log ml WHERE mm.id = ml.member_id AND ml.access_time LIKE '%2017-02-06%');

    EXITS又简称代入查询,就是把主表的每一行代入子表的每一行进行检验,一旦子表中有符合的数据行就返回true,就可以取得主表中代入检验的那一行数据,否则返回false,不可以取得主表中代入检验的那一行数据。同IN不同的是,EXITS后的子语句不查询出结果,所以说SELECT后面的字段没有意义,一般使用*代替,由于EXITS的这种机制,当子表数据量比较大且有冗余字段的时候就很有可能避免了对子表的全表扫描,不像IN那样每次主表数据行来匹配都要进行全表扫描,并返回结果。所以说EXITS类似于两个FOR循环嵌套时,内层的FOR循环里面有 if(xxx){ break; }这种语法。

    以上sql执行时间的平均在34秒左右,比使用IN要快上一些,但是跟表连接查询还不能比。

    但是,在表与表之间没有关联关系时,就只能使用IN了。

    展开全文
  • 子查询就是在一条查询语句中还有其它的查询语句,...子查询的子语句可以在一条sql语句的FROM,JOIN,和WHERE后面,本文主要针对在WHERE后面使用子查询与表连接查询的性能做出一点分析。 对于表连接查询和子查询性...

    声明:本文摘自https://www.cnblogs.com/cdf-opensource-007/p/6540521.html

    子查询就是在一条查询语句中还有其它的查询语句,主查询得到的结果依赖于子查询的结果。

    子查询的子语句可以在一条sql语句的FROM,JOIN,和WHERE后面,本文主要针对在WHERE后面使用子查询与表连接查询的性能做出一点分析。

    对于表连接查询和子查询性能的讨论众说纷纭,普遍认为的是表连接查询的性能要高于子查询。本文将从实验的角度,对这两种查询的性能做出验证,并就实验结果分析两种查询手段的执行流程对性能的影响。

    首先准备两张表

    1,访问日志表mm_log有150829条记录(相关sql文件已放在文章结尾的链接中)。

    2,用户表mm_member有373条记录(相关sql文件已放在文章结尾的链接中)。

    现在要求我们根据这两张表查出2017-02-06那天有那些用户登录过系统。

    我们先来看一下使用表连接查询

    复制代码
    SELECT
        SQL_NO_CACHE mm.*
    FROM
        mm_member mm
    JOIN
        mm_log ml
    ON
        mm.id = ml.member_id
    WHERE
        ml.access_time LIKE '%2017-02-06%'
    GROUP BY
        ml.member_id;
    复制代码

    这里使用了 SQL_NO_CACHE 是因为要多次执行这条sql语句,并计算出这条sql查询所耗费的平均时间,所以要关掉mysql的查询缓存,防止多次执行从缓存中读取数据。

    mm.*是取GROUP BY ml.member_id分组后的诸多临时表的第一行数据,相关用法及原理请参见我的另一篇博客(http://www.cnblogs.com/cdf-opensource-007/p/6502556.html)

    对这条sql语句执行了10次,查询所耗费的平均时间在0.120s左右。

    查询结果:(一共有5个用户访问过系统)

     

    至于以上这条sql的执行流程已经在前几篇博客中描述的很详细了,这里就不再做叙述了。

    下面使用WHERE后使用子查询的方式实现

    SELECT
        SQL_NO_CACHE mm.username
    FROM
        mm_member mm
    WHERE
        mm.id IN(SELECT ml.member_id FROM mm_log ml WHERE ml.access_time LIKE '%2017-02-06%' GROUP BY ml.member_id);

    当我第一次运行这条sql语句的时候,等了十几秒一直没有结果,我以为我的电脑死机,可Navicat显示处理中,最后40多秒的时候才运行出结果,接连运行了好多次在都是41秒左右出结果。

    我们看到执行结果同上。那么使用子查询的性能到底低在哪里呢?

    我的第一种推测是子语句:SELECT ml.member_id FROM mm_log ml WHERE ml.access_time LIKE '%2017-02-06%' GROUP BY ml.member_id耗费了大量的查询时间,因为mm_log这张表中有150829条记录。

    把子语句单拿出来运行一下,发现子语句的运行时间也就在0.111s左右。

    SELECT SQL_NO_CACHE member_id FROM mm_log ml WHERE ml.access_time LIKE '%2017-02-06%' GROUP BY ml.member_id;

    这就说明我的第一种推测是不合理的。

    那就分析下在WHERE后使用子查询IN的执行原理:

    1,IN后面跟的子查询语句的执行结果只能有一列是用来和IN前面的主表的字段匹配的,在这里指的是mm.id。

    2,一条带有子查询的sql语句首先执行的是子语句,主表的数据行按照IN前面主表的字段依次跟子查询的结果进行匹配,子查询中结果中有该数据行对应字段的值,则返回true,该行被WHERE筛选出来。没有则返回false,该行不被筛选。

    3,那么按照2的说法,子查询的效率应该也不低啊,子语句的耗时在0.111s左右,而且主表mm_member和子语句的查询结果相匹配的次数,肯定是要少于表连接查询时数据行间匹配的次数的,但实验结果显示使用子查询的性能确实很低。

    所以我有了第二种推测,主表mm_member数据行的每一行在与IN后面子语句的结果相匹配时,子语句都会重新执行一次,也就是说子语句第一次执行时,不会在内存中有缓存。这类似与使用了两个FOR循环嵌套,外层的FOR循环每拿出一个值,内层的FOR循环都要遍历一次。

    那么根据以上的推测,拿主表mm_member的数据行数乘以子语句的执行时间就应该是整个查询的时间。

    mm_member的数据行数:373

    多次执行子语句算出平均时间在:0.111s

    整个查询耗时的理论时间:41.403s

    多次执行整个查询得出实际查询时间的平均值:40.834s

    计算误差:(理论值-实际值)÷理论值 = 1.37%

    误差还是在可以接受的范围内的,可以证明以上的推测。

    根据以上的实验,我们可以得出的结论是,表连接查询的性能是要高于子查询的。

    另外,对于在子查询中使用IN的性能高还是是用EXITS的性能高,有一种普遍的说法是:

    1,在外表大,内表小,外表中有索引的情况下,使用IN。

    2,在外表小,内表大,内表中有索引的情况下,使用EXITS。

    先介绍一下EXITS的用法,刚好本例符合外表小内表大的情况,就以本例介绍一下。看下SQL:

     

    SELECT
        SQL_NO_CACHE mm.*
    FROM
        mm_member mm
    WHERE
        EXISTS(SELECT * FROM mm_log ml WHERE mm.id = ml.member_id AND ml.access_time LIKE '%2017-02-06%');

     

    EXITS又简称代入查询,就是把主表的每一行代入子表的每一行进行检验,一旦子表中有符合的数据行就返回true,就可以取得主表中代入检验的那一行数据,否则返回false,不可以取得主表中代入检验的那一行数据。同IN不同的是,EXITS后的子语句不查询出结果,所以说SELECT后面的字段没有意义,一般使用*代替,由于EXITS的这种机制,当子表数据量比较大且有冗余字段的时候就很有可能避免了对子表的全表扫描,不像IN那样每次主表数据行来匹配都要进行全表扫描,并返回结果。所以说EXITS类似于两个FOR循环嵌套时,内层的FOR循环里面有 if(xxx){ break; }这种语法。

    以上sql执行时间的平均在34秒左右,比使用IN要快上一些,但是跟表连接查询还不能比。

    但是,在表与表之间没有关联关系时,就只能使用IN了。

    转载于:https://www.cnblogs.com/quyanhui/p/9994725.html

    展开全文
  • 子查询就是在一条查询语句中还有其它的...子查询的子语句可以在一条sql语句的FROM,JOIN,和WHERE后面,本文主要针对在WHERE后面使用子查询与表连接查询的性能做出一点分析。 对于表连接查询和子查询性能的讨...

     

    https://www.cnblogs.com/cdf-opensource-007/p/6540521.html

     

     

    子查询就是在一条查询语句中还有其它的查询语句,主查询得到的结果依赖于子查询的结果。

    子查询的子语句可以在一条sql语句的FROM,JOIN,和WHERE后面,本文主要针对在WHERE后面使用子查询与表连接查询的性能做出一点分析。

    对于表连接查询和子查询性能的讨论众说纷纭,普遍认为的是表连接查询的性能要高于子查询。本文将从实验的角度,对这两种查询的性能做出验证,并就实验结果分析两种查询手段的执行流程对性能的影响。

    首先准备两张表

    1,访问日志表mm_log有150829条记录(相关sql文件已放在文章结尾的链接中)。

    2,用户表mm_member有373条记录(相关sql文件已放在文章结尾的链接中)。

    现在要求我们根据这两张表查出2017-02-06那天有那些用户登录过系统。

    我们先来看一下使用表连接查询

    复制代码

    SELECT
        SQL_NO_CACHE mm.*
    FROM
        mm_member mm
    JOIN
        mm_log ml
    ON
        mm.id = ml.member_id
    WHERE
        ml.access_time LIKE '%2017-02-06%'
    GROUP BY
        ml.member_id;

    复制代码

    这里使用了 SQL_NO_CACHE 是因为要多次执行这条sql语句,并计算出这条sql查询所耗费的平均时间,所以要关掉mysql的查询缓存,防止多次执行从缓存中读取数据。

    mm.*是取GROUP BY ml.member_id分组后的诸多临时表的第一行数据,相关用法及原理请参见我的另一篇博客(http://www.cnblogs.com/cdf-opensource-007/p/6502556.html)

    对这条sql语句执行了10次,查询所耗费的平均时间在0.120s左右。

    查询结果:(一共有5个用户访问过系统)

     

    至于以上这条sql的执行流程已经在前几篇博客中描述的很详细了,这里就不再做叙述了。

    下面使用WHERE后使用子查询的方式实现

    SELECT
        SQL_NO_CACHE mm.username
    FROM
        mm_member mm
    WHERE
        mm.id IN(SELECT ml.member_id FROM mm_log ml WHERE ml.access_time LIKE '%2017-02-06%' GROUP BY ml.member_id);

    当我第一次运行这条sql语句的时候,等了十几秒一直没有结果,我以为我的电脑死机,可Navicat显示处理中,最后40多秒的时候才运行出结果,接连运行了好多次在都是41秒左右出结果。

    我们看到执行结果同上。那么使用子查询的性能到底低在哪里呢?

    我的第一种推测是子语句:SELECT ml.member_id FROM mm_log ml WHERE ml.access_time LIKE '%2017-02-06%' GROUP BY ml.member_id耗费了大量的查询时间,因为mm_log这张表中有150829条记录。

    把子语句单拿出来运行一下,发现子语句的运行时间也就在0.111s左右。

    SELECT SQL_NO_CACHE member_id FROM mm_log ml WHERE ml.access_time LIKE '%2017-02-06%' GROUP BY ml.member_id;

    这就说明我的第一种推测是不合理的。

    那就分析下在WHERE后使用子查询IN的执行原理:

    1,IN后面跟的子查询语句的执行结果只能有一列是用来和IN前面的主表的字段匹配的,在这里指的是mm.id。

    2,一条带有子查询的sql语句首先执行的是子语句,主表的数据行按照IN前面主表的字段依次跟子查询的结果进行匹配,子查询中结果中有该数据行对应字段的值,则返回true,该行被WHERE筛选出来。没有则返回false,该行不被筛选。

    3,那么按照2的说法,子查询的效率应该也不低啊,子语句的耗时在0.111s左右,而且主表mm_member和子语句的查询结果相匹配的次数,肯定是要少于表连接查询时数据行间匹配的次数的,但实验结果显示使用子查询的性能确实很低。

    所以我有了第二种推测,主表mm_member数据行的每一行在与IN后面子语句的结果相匹配时,子语句都会重新执行一次,也就是说子语句第一次执行时,不会在内存中有缓存。这类似与使用了两个FOR循环嵌套,外层的FOR循环每拿出一个值,内层的FOR循环都要遍历一次。

    那么根据以上的推测,拿主表mm_member的数据行数乘以子语句的执行时间就应该是整个查询的时间。

    mm_member的数据行数:373

    多次执行子语句算出平均时间在:0.111s

    整个查询耗时的理论时间:41.403s

    多次执行整个查询得出实际查询时间的平均值:40.834s

    计算误差:(理论值-实际值)÷理论值 = 1.37%

    误差还是在可以接受的范围内的,可以证明以上的推测。

    根据以上的实验,我们可以得出的结论是,表连接查询的性能是要高于子查询的。

    另外,对于在子查询中使用IN的性能高还是是用EXITS的性能高,有一种普遍的说法是:

    1,在外表大,内表小,外表中有索引的情况下,使用IN。

    2,在外表小,内表大,内表中有索引的情况下,使用EXITS。

    先介绍一下EXITS的用法,刚好本例符合外表小内表大的情况,就以本例介绍一下。看下SQL:

     

    SELECT
        SQL_NO_CACHE mm.*
    FROM
        mm_member mm
    WHERE
        EXISTS(SELECT * FROM mm_log ml WHERE mm.id = ml.member_id AND ml.access_time LIKE '%2017-02-06%');

     

    EXITS又简称代入查询,就是把主表的每一行代入子表的每一行进行检验,一旦子表中有符合的数据行就返回true,就可以取得主表中代入检验的那一行数据,否则返回false,不可以取得主表中代入检验的那一行数据。同IN不同的是,EXITS后的子语句不查询出结果,所以说SELECT后面的字段没有意义,一般使用*代替,由于EXITS的这种机制,当子表数据量比较大且有冗余字段的时候就很有可能避免了对子表的全表扫描,不像IN那样每次主表数据行来匹配都要进行全表扫描,并返回结果。所以说EXITS类似于两个FOR循环嵌套时,内层的FOR循环里面有 if(xxx){ break; }这种语法。

    以上sql执行时间的平均在34秒左右,比使用IN要快上一些,但是跟表连接查询还不能比。

    但是,在表与表之间没有关联关系时,就只能使用IN了。

     

    sql 文件位置:http://pan.baidu.com/s/1gfLwIwr

    展开全文
  • 子查询的子语句可以在一条sql语句的FROM,JOIN,和WHERE后面,本文主要针对在WHERE后面使用子查询与表连接查询的性能做出一点分析。 对于表连接查询和子查询性能的讨论众说纷纭,普遍认为的是表连接查询的性能要...

    子查询就是在一条查询语句中还有其它的查询语句,主查询得到的结果依赖于子查询的结果。

    子查询的子语句可以在一条sql语句的FROM,JOIN,和WHERE后面,本文主要针对在WHERE后面使用子查询与表连接查询的性能做出一点分析。

    对于表连接查询和子查询性能的讨论众说纷纭,普遍认为的是表连接查询的性能要高于子查询。本文将从实验的角度,对这两种查询的性能做出验证,并就实验结果分析两种查询手段的执行流程对性能的影响。

    首先准备两张表

    1,访问日志表mm_log有150829条记录(相关sql文件已放在文章结尾的链接中)。

    2,用户表mm_member有373条记录(相关sql文件已放在文章结尾的链接中)。

    现在要求我们根据这两张表查出2017-02-06那天有那些用户登录过系统。

    我们先来看一下使用表连接查询

    复制代码

    SELECT
        SQL_NO_CACHE mm.*
    FROM
        mm_member mm
    JOIN
        mm_log ml
    ON
        mm.id = ml.member_id
    WHERE
        ml.access_time LIKE '%2017-02-06%'
    GROUP BY
        ml.member_id;

    复制代码

    这里使用了 SQL_NO_CACHE 是因为要多次执行这条sql语句,并计算出这条sql查询所耗费的平均时间,所以要关掉mysql的查询缓存,防止多次执行从缓存中读取数据。

    mm.*是取GROUP BY ml.member_id分组后的诸多临时表的第一行数据。

    对这条sql语句执行了10次,查询所耗费的平均时间在0.120s左右。

    查询结果:(一共有5个用户访问过系统)

     

    至于以上这条sql的执行流程已经在前几篇博客中描述的很详细了,这里就不再做叙述了。

    下面使用WHERE后使用子查询的方式实现

    SELECT
        SQL_NO_CACHE mm.username
    FROM
        mm_member mm
    WHERE
        mm.id IN(SELECT ml.member_id FROM mm_log ml WHERE ml.access_time LIKE '%2017-02-06%' GROUP BY ml.member_id);

    当我第一次运行这条sql语句的时候,等了十几秒一直没有结果,我以为我的电脑死机,可Navicat显示处理中,最后40多秒的时候才运行出结果,接连运行了好多次在都是41秒左右出结果。

    我们看到执行结果同上。那么使用子查询的性能到底低在哪里呢?

    我的第一种推测是子语句:SELECT ml.member_id FROM mm_log ml WHERE ml.access_time LIKE '%2017-02-06%' GROUP BY ml.member_id耗费了大量的查询时间,因为mm_log这张表中有150829条记录。

    把子语句单拿出来运行一下,发现子语句的运行时间也就在0.111s左右。

    SELECT SQL_NO_CACHE member_id FROM mm_log ml WHERE ml.access_time LIKE '%2017-02-06%' GROUP BY ml.member_id;

    这就说明我的第一种推测是不合理的。

    那就分析下在WHERE后使用子查询IN的执行原理:

    1,IN后面跟的子查询语句的执行结果只能有一列是用来和IN前面的主表的字段匹配的,在这里指的是mm.id。

    2,一条带有子查询的sql语句首先执行的是子语句,主表的数据行按照IN前面主表的字段依次跟子查询的结果进行匹配,子查询中结果中有该数据行对应字段的值,则返回true,该行被WHERE筛选出来。没有则返回false,该行不被筛选。

    3,那么按照2的说法,子查询的效率应该也不低啊,子语句的耗时在0.111s左右,而且主表mm_member和子语句的查询结果相匹配的次数,肯定是要少于表连接查询时数据行间匹配的次数的,但实验结果显示使用子查询的性能确实很低。

    所以我有了第二种推测,主表mm_member数据行的每一行在与IN后面子语句的结果相匹配时,子语句都会重新执行一次,也就是说子语句第一次执行时,不会在内存中有缓存。这类似与使用了两个FOR循环嵌套,外层的FOR循环每拿出一个值,内层的FOR循环都要遍历一次。

    那么根据以上的推测,拿主表mm_member的数据行数乘以子语句的执行时间就应该是整个查询的时间。

    mm_member的数据行数:373

    多次执行子语句算出平均时间在:0.111s

    整个查询耗时的理论时间:41.403s

    多次执行整个查询得出实际查询时间的平均值:40.834s

    计算误差:(理论值-实际值)÷理论值 = 1.37%

    误差还是在可以接受的范围内的,可以证明以上的推测。

    根据以上的实验,我们可以得出的结论是,表连接查询的性能是要高于子查询的。

    另外,对于在子查询中使用IN的性能高还是是用EXITS的性能高,有一种普遍的说法是:

    1,在外表大,内表小,外表中有索引的情况下,使用IN。

    2,在外表小,内表大,内表中有索引的情况下,使用EXITS。

    先介绍一下EXITS的用法,刚好本例符合外表小内表大的情况,就以本例介绍一下。看下SQL:

     

    SELECT
        SQL_NO_CACHE mm.*
    FROM
        mm_member mm
    WHERE
        EXISTS(SELECT * FROM mm_log ml WHERE mm.id = ml.member_id AND ml.access_time LIKE '%2017-02-06%');

     

    EXITS又简称代入查询,就是把主表的每一行代入子表的每一行进行检验,一旦子表中有符合的数据行就返回true,就可以取得主表中代入检验的那一行数据,否则返回false,不可以取得主表中代入检验的那一行数据。同IN不同的是,EXITS后的子语句不查询出结果,所以说SELECT后面的字段没有意义,一般使用*代替,由于EXITS的这种机制,当子表数据量比较大且有冗余字段的时候就很有可能避免了对子表的全表扫描,不像IN那样每次主表数据行来匹配都要进行全表扫描,并返回结果。所以说EXITS类似于两个FOR循环嵌套时,内层的FOR循环里面有 if(xxx){ break; }这种语法。

    以上sql执行时间的平均在34秒左右,比使用IN要快上一些,但是跟表连接查询还不能比。

    但是,在表与表之间没有关联关系时,就只能使用IN了。

    展开全文
  • 子查询的子语句可以在一条sql语句的FROM,JOIN,和WHERE后面,本文主要针对在WHERE后面使用子查询与表连接查询的性能做出一点分析。对于表连接查询和子查询性能的讨论众说纷纭,普遍认为的是表连接查询的性能要高于...
  • 1.查询的信息来源于多张表,则可以通过两两相连的方式建立多表连接查询 以下是正常多表查询语法,查询三张表的所有数据信息 2.简单多表查询要比多表查询写法更简单,效果是一样的, 简单多表查询是在from后面加上...
  • Mysql查询时的多表连接查询举个栗子等值连接自然连接:NATUEAL JOIN内连接:INNER JOIN或JOIN左外连接:LEFT OUTER JOIN或者LEFT JOIN右外连接:RIGHT OUTER JOIN或者RIGHT JOIN交叉连接(笛卡尔连接) 举个栗子 ...
  • sql多表连接详解

    2020-06-12 00:25:51
    除了我们在上面的例子中使用的 INNER JOIN(内连接),我们还可以使用其他几种连接。 下面列出了您可以使用的 JOIN 类型,以及它们之间的差异。 JOIN: 如果中有至少一个匹配,则返回行 LEFT JOIN: 即使右中没有...
  • inner join,left join,right,join 三种表连接的方式区别自行查找,或者可以参考链接:https://www.cnblogs.com/FENGXUUEILIN/p/10039699.html 最近在完成一个查询时,遇到这个问题,记录一下。 两张测试表: product...
  • sql查询这个东西, 要说它简单, ...在连接查询语法中,另人迷惑首当其冲的就要属on筛选和where筛选的区别了, 在我们编写查询的时候, 筛选条件的放置不管是在on后面还是where后面, 查出来的结果总是一样的, 既然如
  • 连接分为:内连接、外连接、交叉连接  一、内连接——最常用  定义:仅将两个中满足连接条件的行组合起来作为结果集。  在内连接中,只有在两个...(1)列名中的列名可以出自后面的两个,但如果两个
  • on where 是指这前后两个连接条件只有on后面的一个,然后对连接好的结果,去执行where条件查询,where后面的列可以不是连接相关的列,where后面出现的是某一个列的条件,是对行的筛选条件,不是列与列的连接关系...
  • 连接分为:内连接、外连接、交叉连接一、内连接——最常用 定义:仅将两个中满足连接条件的行组合起来作为结果集。...(1)列名中的列名可以出自后面的两个,但如果两个中有同名列,应在...
  •  在连接查询语法中,另人迷惑首当其冲的要属on筛选和where筛选的区别了, 在我们编写查询的时候, 筛选条件的放置不管是在on后面还是where后面, 查出来的结果总是一样的, 既然如此,那为什么还要多此一举的让...
  • 一、的加法加法:UNION语法:SELECT二、连接语法:SELECT 内连接(★): ...内连接SELECT 分类:等值、非等值、自连接特点:①添加排序、分组、筛选②INNER可以省略③筛选条件放在 WHERE后面连接条件放在 O...
  • ​ 分组函数可以过滤组信息,having后面可以使用组函数。在使用group by时,select后面可以使用多行函数也可以使用字段,不过字段必须与分组字段相同,且having后面的字段也如此。在任何时候where后面都不可以使用...
  • 前言 相信对于每位程序员来说,sql查询这个东西, 要说它简单, ...在连接查询语法中,另人迷惑首当其冲的就要属on筛选和where筛选的区别了, 在我们编写查询的时候, 筛选条件的放置不管是在on后面还是where后面
  • sql中多表连接中需要注意的事项

    千次阅读 2016-11-07 18:15:02
    1.在数据库中,通常可以通过查看执行计划了解sql语句的执行顺序,以及花费的时间等,但在使用left join时,需要特别注意的是,如果第二张表有筛选条件,应该将连接条件写在join里面,而不是写在where后面....
  • A\B\C三个,A和B中只有一个表可以查询到registno ``` select registno, status from A where registno = '123456'; select registno, status from B where registno = '123456'; select pumpid from C; `...
  • sql查询这个东西, 要说它简单,...在连接查询语法中,另人迷惑首当其冲的就要属on筛选和where筛选的区别了, 在我们编写查询的时候, 筛选条件的放置不管是在on后面还是where后面, 查出来的结果总是一样的, 既然如此
  • 在内连接中,只有在两个中匹配的行才能在结果集中出现 关键词:INNER JOIN 格式:SELECT 列名 FROM 表名1 [INNER] JOIN 表名2 ON或WHERE 条件表达式 说明: (1)列名中的列名可以出自后面的两个,但如果两...
  • 这个错误in where clause is ambiguous多半是因为多查询的时候几个中同时出现了某个相同的列名,而在查询条件WHERE后面又没有指定是那个,而引起的 又或者是查询结果里面有两个相同的列名,而没有指定是哪个...
  • sql 199标准 连接查询

    2020-10-15 11:02:41
    3.筛选条件放在where后面,连接条件放在on后面,提高分离性,便于阅读。 4.inner join 连接和sq192语法中的等值连接效果是一样的,都是查询多的交集。 等值连接 非等值连接连接 ...
  • 时的联条件可以写在on后面,也可以写在where后面,有什么区别? 第一种:等值连接时的联条件 写在 on 后面: select * from A a join B b on a.xx = b.yy 写在where后面: select * from A a join B b where...
  • 而且,可以同时使用多个AND关键字,这样可以连接更多的条件表达式。 (3)模糊查询 like 像 LIKE关键字可以匹配字符串是否相等。如果字段的值与指定的字符串相匹配,则满足查询条件,该纪录将被查询出来。如果与...
  • on后面的是连接条件,代表两个建立关系所遵循的规则 where后面可以看作是筛选条件,是对最终结果集进行过滤所遵循的规则 注意: Select A.name,B.name from A inner join B on A.id=B.id和 ...
  • Oracle的连接

    千次阅读 2012-10-23 12:31:27
    连接分为:内连接、外连接、交叉连接 一、内连接——最常用 定义:仅将两个中满足连接条件的行组合起来作为结果集。 在内连接中,只有在两个中匹配的行才能...(1)列名中的列名可以出自后面的两个,但如
  • sql连接问题

    2012-07-10 12:24:00
    连接分为:内连接、外连接、交叉连接 一、内连接——最常用 定义:仅将两个中满足连接条件的行组合起来作为结果集。 在内连接中,只有在两个中匹配... (1)列名中的列名可以出自后面的两个,但如果两个...

空空如也

空空如也

1 2 3 4 5 ... 13
收藏数 246
精华内容 98
关键字:

表连接后面可以接where