mysql join 和left join 对于索引的问题

mysql join 和left join 对于索引的问题

 今天遇到一个left join优化的问题,搞了一下午,中间查了不少资料,对MySQL的查询计划还有查询优化有了更进一步的了解,做一个简单的记录: 

select c.* from hotel_info_original c 
left join hotel_info_collection h 
on c.hotel_type=h.hotel_type and c.hotel_id =h.hotel_id 
where h.hotel_id is null 

   这个sql是用来查询出c表中有h表中无的记录,所以想到了用left join的特性(返回左边全部记录,右表不满足匹配条件的记录对应行返回null)来满足需求,不料这个查询非常慢。先来看查询计划: 



   rows代表这个步骤相对上一步结果的每一行需要扫描的行数,可以看到这个sql需要扫描的行数为35773*8134,非常大的一个数字。本来c和h表的记录条数分别为40000+和10000+,这几乎是两个表做笛卡尔积的开销了(select * from c,h)。 
于是我上网查了下MySQL实现join的原理,原来MySQL内部采用了一种叫做 nested loop join的算法。Nested Loop Join 实际上就是通过驱动表的结果集作为循环基础数据,然后一条一条的通过该结果集中的数据作为过滤条件到下一个表中查询数据,然后合并结果。如果还有第三个参与 Join,则再通过前两个表的 Join 结果集作为循环基础数据,再一次通过循环查询条件到第三个表中查询数据,如此往复,基本上MySQL采用的是最容易理解的算法来实现join。所以驱动表的选择非常重要,驱动表的数据小可以显著降低扫描的行数。 
那么为什么一般情况下join的效率要高于left join很多?很多人说不明白原因,只人云亦云,我今天下午感悟出来了一点。一般情况下参与联合查询的两张表都会一大一小,如果是join,在没有其他过滤条件的情况下MySQL会选择小表作为驱动表,但是left join一般用作大表去join小表,而left join本身的特性决定了MySQL会用大表去做驱动表,这样下来效率就差了不少,如果我把上面那个sql改成 
select c.* from hotel_info_original c 
join hotel_info_collection h 
on c.hotel_type=h.hotel_type and c.hotel_id =h.hotel_id 
查询计划如下: 

 

     很明显,MySQL选择了小表作为驱动表,再配合(hotel_id,hotel_type)上的索引瞬间降低了好多个数量级。。。。。 
另外,我今天还明白了一个关于left join 的通用法则,即:如果where条件中含有右表的非空条件(除开is null),则left join语句等同于join语句,可直接改写成join语句。 
后记: 
随着查看MySQL reference manual对这个问题进行了更进一步的了解。MySQL在执行join时会把join分为system/const/eq_ref/ref/range/index/ALl等好几类,连接的效率从前往后 
依次递减,对于我的第一个sql,连接类型是index,所以几乎是全表扫描的效果。但是我很奇怪我在(hotel_id,hotel_type)两列上声明了unique key,根据官方文档连接类型应该是eq_ref才对, 
     这个问题一直困扰了我两天,在google和stackoverflow上都没有找到能够解释这个问题的文章,莫非我这个问题无解了?抱着解决这个问题的决心今天又翻看了一遍MySQL官方文档 
关于优化查询的部分,看到了这样一句:这里的一个问题是MySQL能更高效地在声明具有相同类型和尺寸的列上使用索引。我感觉我找到了问题所在,于是我将original和 collection表的(hotel_type,hotel_id)的encoding和collation(决定字符比较的规则)全部改成统一的utf8_general_ci,然后再次运行第一条sql的查询计划,得到如下结果: 



     连接类型已经由index优化到了ref,如果将hotel_type申明为not null可以优化到eq_ref,不过这里影响不大了,优化后这条sql能在0.01ms内运行完。 

     那么如何优化left join: 
1、条件中尽量能够过滤一些行将驱动表变得小一点,用小表去驱动大表 

2、右表的条件列一定要加上索引(主键、唯一索引、前缀索引等),最好能够使type达到range及以上(ref,eq_ref,const,system) 

3、无视以上两点,一般不要用left join~~! 

MySQL中的LEFT JOIN用于从左表(在LEFT JOIN关键字左边的表)返回所有记录,以及右表(在LEFT JOIN关键字右边的表)中匹配的记录。当涉及到视图(view)和索引时,可能出现索引失效的情况。 首先,MySQL中的视图是一个虚拟表,其内容由查询定义。视图包含的数据并不实际存在于数据库中,而是在查询视图时动态生成。因此,视图上的索引通常与物理表上的索引不同,它们是视图定义中的SELECT语句上的索引,并不总是能够直接被利用。 当你执行一个包含LEFT JOIN的查询,并且涉及到视图时,可能遇到索引失效的情况,这通常与以下因素有关: 1. 视图的索引策略:视图的索引并不是物理上存在于数据库中,它们依赖于视图所基于的基础表的索引。当使用LEFT JOIN时,如果连接条件或者WHERE子句中的条件没有利用到有效的索引,或者优化器认为全表扫描更加高效,那么索引就可能不被使用。 2. 优化器的决策:MySQL的优化器决定是否使用索引以及如何使用索引。在复杂的查询中,特别是涉及到视图和多表连接时,优化器可能因为各种统计信息和成本模型的计算结果而选择不使用索引,从而导致全表扫描。 3. 视图更新规则:MySQL中对视图的更新有一定限制,特别是在涉及到复杂查询和多表连接的视图。如果视图定义中包含复杂的JOIN操作或者聚合函数,那么可能无法在视图上直接创建索引,进而影响到基于视图的查询性能。 为了确保LEFT JOIN查询在涉及视图时索引的有效使用,你可以采取以下措施: - 确保基础表上有适当的索引,并且这些索引能够被视图中的查询利用。 - 分析查询计划,查看是否有不合理的全表扫描发生,如果有,可以尝试重写查询语句来提高索引的利用率。 - 使用EXPLAIN命令来了解查询是如何执行的,以及为什么优化器没有使用某些索引
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值