美文网首页
in子查询陷阱

in子查询陷阱

作者: 罗亮leon | 来源:发表于2016-12-01 10:08 被阅读0次

    对于in子查询性能,众说纷纭。有的人说 in 子查询性能很差,不能使用索引。而有人说 in 子查询能用索引,而且性能很好。

    今天我就给大家做个实验,来验证这些说法。
    首先,我使用MySQL_5.1.73做测试。
    有一个test库,库中有两张表:
    data_school:全国各地的学校

    Paste_Image.png

    t1 :三个学校id

    Paste_Image.png

    我们来演示两种in子查询:
    第一种:直接输入具体的值:

    select * from data_school where id in (1101010002,1101010012,1101010014);
    select * from data_school where id in ( select id from t1 );
    
    Paste_Image.png

    大家可以看到,两者的性能都不在一个数量级上,非常的夸张。
    我们再用explain去分析它们使用索引的情况。

    对于explain与 profiling如果还不了解的话,可以看我上一篇文章。

    Paste_Image.png

    对于第一条语句,大家可以看到,是一个simple 查询,没有子查询,而且使用了primary key索引。

    我们再看看第二条语句:

    Paste_Image.png

    首先是对data_school做了全盘扫描,这个是比较失败的查询。
    这条查询和我们的思维不太一样,我们一般会认为
    先执行 select id from t1,
    再执行select * from data_school。
    而实际的情况是,select * from data_school做全盘扫描,然后再一条条的去匹配表t1。

    现在大家明白了吧,遇到这种问题,不能按我们的直觉去判断,要通过具体的实验分析获取结果。

    最后注意一点

    MySQL升级到5.6的时候,这个问题已经被修复,我再给大家看一个在MySQL5.6中的实验。直接上图:

    Paste_Image.png

    大家可以看到没啥大的差距。


    Paste_Image.png

    看下图,大家注意到没有,相比5.1.37,它们查询的顺序发生了变化,先查t1,使用primary key。
    然后再查data_school,也使用了primary key。两条查询都是simple类型。


    Paste_Image.png

    MySQL5.6修复了这个问题,这大概就是为什么有人说性能差,有人说性能好的原因吧!
    建议大家使用较高版本的MySQL。

    相关文章

      网友评论

          本文标题:in子查询陷阱

          本文链接:https://www.haomeiwen.com/subject/mzkxmttx.html