mysql left join 索引问题

left join需要注意事项

left join经常出现效率问题 比如以下SQL, 可以不了解以下SQL是干什么用的, 只需要了解表a表符合条件的有3W+数据, b 表有3W+数据

explain  SELECT a.not_match_count as number, b.province_name as province  from renting_analyze_summary as a left JOIN ds_dict_cmc_displocal  b ON (a.display_local_showname = b.areaname 

) where a.job_id = 1919  and a.channel =1

最开始a表(job_id channel)建立了索引。  b表没有建索引。 查询执行特别看 使用explain 查看

left join先查询a表中的数据有3W+,ON (a.display_local_showname = b.areaname )相当于循环3W+次。 每次执行一遍

select areaname from b where b.areaname='****' 

b表中areaname没有索引,所以要全表查询。 这样执行时间就成为3W*3W, 所以left join语句应该在 后表的关联字段中加索引。

加入索引以后再查看效率。 那是相当快啊, 使用explain查看索引情况 执行时间 3W*1

 

总结:

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、付费专栏及课程。

余额充值