查询优化--小表驱动大表(In,Exists区别)

Mysql 系列文章主页

===============

本文将以真实例子来讲解小表驱动大表(In,Exists区别)

1 准备数据

1.1 创建表、函数、存储过程

参照  这篇(调用函数和存储过程批量插入数据)  文章中的第 1-7 步,注意,不要执行第8步

1.2 插入数据

现在来执行第8步。

1.2.1 向 Department 表中插入 100 条记录

CALL insert_dept(1000, 100)

1.2.2 向 Employee 表中插入 100000 条记录

CALL insert_employee(100000000, 100000);

2 测试

2.1 查询所有 Employee 信息,要求是:Employee 的 dept_id 存在于 Department 表中

Case#1:用 IN

SELECT * FROM employee WHERE dept_id IN (SELECT id FROM department);

结果:在我本机测试了数十次,耗时大概是  120--130 ms

Case#2:用 EXISTS

SELECT * FROM employee e WHERE EXISTS (SELECT 1 FROM department d WHERE e.dept_id = d.id);

结果:在我本机测试了数十次,耗时大概是  350--370 ms

2.2 查询所有 Department 信息,要求是:至少有一条 Employee 记录的 dept_id 对应 Department(或者说:此部门下至少有一条员工记录)

Case#3:用 EXISTS

SELECT * FROM department d WHERE EXISTS (SELECT 1 FROM employee e WHERE d.id = e.dept_id);

结果:在我本机测试了数十次,耗时大概是  4--6 ms

Case#4:用 IN

SELECT * FROM department WHERE id IN (SELECT dept_id FROM employee);

结果:在我本机测试了数十次,耗时大概是  50--55 ms

2.3 分析并总结

在 Case#1,#2 中,Employee 是大表,Department 是小表,用 IN(Department) 的效果较好(大概是用 EXISTS 时间的三分之一)====> IN 后面跟小表~

在 Case#3,#4 中,Employee 是大表,Department 是小表,用 EXISTS(Employee) 的效果较好(大概是用 IN 时间的十分之一)====> EXISTS 后面跟大表~

记忆:IN 后面跟小表~EXISTS 后面跟大表~~~因为 IN 这个单词比 EXISTS 单词更短(更小),EXISTS 这个单词比 IN 更长(更大)

2.4 进一步分析

至于为什么 Case#1 优于 Case#2,Case#3 优于 Case#4,还没搞清楚到底是为什么,,,,,TODO

一篇文章可供参考:https://www.cnblogs.com/beijingstruggle/p/5885137.html

3 结论

小表驱动大表

IN 小 EXISTS 大

原文地址:https://www.cnblogs.com/cyhbyw/p/8853509.html

时间: 2024-10-13 00:34:16

查询优化--小表驱动大表(In,Exists区别)的相关文章

Mysql优化原则_小表驱动大表IN和EXISTS的合理利用

//假设一个for循环for($i = 0; $i < 10000; $i++) { for ($j = 0; $i < 50; $j++) { }} for($i = 0; $i < 50; $i++) { for ($j = 0; $i < 10000; $j++) { }} 看以上两个for循环,总共循环的次数是一样的.但是对于mysql数据库而言,并不是这样了,我们尽量选择第②个for循环,也就是小表驱动大表.数据库最伤神的就是跟程序链接释放,第一个建立了10000次链接,

小表驱动大表, 兼论exists和in

给出两个表,A和B,A和B表的数据量, 当A小于B时,用exists select * from A where exists (select * from B where A.id=B.id) exists的实现,相当于外表循环,每次循环对内表进行查询? for i in A for j in B if j.id == i.id then .... 相反,如果A大于B的时候,则用in select * from A where id in (select id from B) 这种在逻辑上类似

hive join 优化 --小表join大表

1.小.大表 join 在小表和大表进行join时,将小表放在前边,效率会高,hive会将小表进行缓存. 2.mapjoin 使用mapjoin将小表放入内存,在map端和大表逐一匹配,从而省去reduce. 例子: select /*+MAPJOIN(b)*/ a.a1,a.a2,b.b2 from tablea a JOIN tableb b ON a.a1=b.b1 在0.7版本后,也可以用配置来自动优化 set hive.auto.convert.join=true;

【Spark调优】小表join大表数据倾斜解决方案

[使用场景] 对RDD使用join类操作,或者是在Spark SQL中使用join语句时,而且join操作中的一个RDD或表的数据量比较小(例如几百MB或者1~2GB),比较适用此方案.. [解决方案] 小表join大表转为小表broadcast+map大表实现.具体为: 普通的join是会shuffle的,而一旦shuffle,就相当于会将相同key的数据拉取到一个shuffle read task中再进行join,此时就是reduce join,此时如果发生数据倾斜,影响处理性能,而此时恰好

Hive中小表与大表关联(join)的性能分析【转】

Hive中小表与大表关联(join)的性能分析 [转自:http://blog.sina.com.cn/s/blog_6ff05a2c01016j7n.html] 经常看到一些Hive优化的建议中说当小表与大表做关联时,把小表写在前面,这样可以使Hive的关联速度更快,提到的原因都是说因为小表可以先放到内存中,然后大表的每条记录再去内存中检测,最终完成关联查询.这样的原因看似合理,但是仔细推敲,又站不住脚跟. 多小的表算小表?如果所谓的小表在内存中放不下怎么办?我用2个只有几条记录的表做关联查询

【Spark调优】大表join大表,少数key导致数据倾斜解决方案

[使用场景] 两个RDD进行join的时候,如果数据量都比较大,那么此时可以sample看下两个RDD中的key分布情况.如果出现数据倾斜,是因为其中某一个RDD中的少数几个key的数据量过大,而另一个RDD中的所有key都分布比较均匀,此时可以考虑采用本解决方案. [解决方案] 对有数据倾斜那个RDD,使用sample算子采样出一份样本,统计下每个key的数量,看看导致数据倾斜数据量最大的是哪几个key. 然后将这几个key对应的数据从原来的RDD中拆分出来,形成一个单独的RDD,并给每个ke

大数据开发实战:Hive优化实战3-大表join大表优化

5.大表join大表优化 如果Hive优化实战2中mapjoin中小表dim_seller很大呢?比如超过了1GB大小?这种就是大表join大表的问题.首先引入一个具体的问题场景,然后基于此介绍各自优化方案. 5.1.问题场景 问题场景如下: A表为一个汇总表,汇总的是卖家买家最近N天交易汇总信息,即对于每个卖家最近N天,其每个买家共成交了多少单,总金额是多少,假设N取90天,汇总值仅取成交单数.A表的字段有:buyer_id. seller_id.pay_cnt_90day. B表为卖家基本信

有一个大表,大表由于录入时候有个空置,现在将空置赋予日期

1.该表很大,8t,由三列,其中create_time,现在要求修改成非空值,由于数据量比较大,因此采用分批来增加. 脚本如下create or replace procedure PRC_UPDATE_CREATE_TIME isstart_num integer;start_date date;total number;update_count integer;per_loop_count integer;begindbms_output.put_line('Start to batch u

PLSQL_Oracle分区表和相应的分区索引管理和使用(案例)(创建交易表等大表时进行分区提高效率)

2014-08-22 BaoXinjian 一.摘要 1.分区表: 随着表的不断增大,对于新纪录的增加.查找.删除等(DML)的维护也更加困难.对于数据库中的超大型表,可通过把它的数据分成若干个小表,从而简化数据库的管理活动.对于每一个简化后的小表,我们称为一个单个的分区 对于分区的访问,我们不需要使用特殊的SQL查询语句或特定的DML语句,而且可以单独的操作单个分区,而不是整个表.同时可以将不同分区的数据放置到不同的表空间,比如将不同年份的销售数据,存放在不同的表空间,即年的销售数据存放到TB