MySQL 使用 OR 条件导致索引失效

文章讨论了在MySQL中,当查询语句包含OR条件且涉及大量数据时,响应时间会变长。通过创建索引和分析查询执行计划,发现OR条件可能导致索引失效。解决方法是使用UNION或UNIONALL分开查询,分别利用索引。UNION和UNIONALL的区别在于是否去除重复和是否排序,以及效率差异。最后,解释了EXPLAIN输出的关键列,帮助理解查询性能。
摘要由CSDN通过智能技术生成

背景:需要根据工号或英文名带出中文名,但数据量过大,导致响应时间过长

查询工号为 x20230506 或者英文名是 codeporter 的用户信息

select * from user_test where login="x20230506" or login_id="codeporter"

查看MySQL版本:

select version();
version()
8.0.18

创建普通索引

alter table  user_test add index user_idx_login(login)
alter table  user_test add index user_idx_login_id(login_id)

使用EXPLAIN分析后面SELECT语句的执行情况,并且能够分析出所查询表的一些特征。 

explain select * from user_test where login="x20230506" or login_id="codeporter"  

查询条件中有or,即使两个条件都带索引也会失效  

idselect_typetablepartitionstypepossible_keyskeykey_lenrefrowsfilteredExtra
1SIMPLEuser_testNULLALLuser_idx_login,user_idx_login_idNULLNULLNULL1100Using where

解决办法:优化的方法是改成 UNION或者UNION ALL,分成多个 sql,走各自的索引。

UNION和UNION ALL的区别:

1.对重复结果的处理:UNION会去掉重复记录,UNION ALL不会

2.对排序的处理:UNION会排序,UNION ALL只是简单地将两个结果集合并

3.效率方面的区别:因为UNION 会做去重和排序处理,因此效率比UNION ALL慢很多

explain select * from ddc.user_test where login="x20230506" union all select * from ddc.user_test where login_id="codeporter";
idselect_typetablepartitionstypepossible_keyskeykey_lenrefrowsfilteredExtra
1PRIMARYuser_testNULLrefuser_idx_loginuser_idx_login202const1100NULL
2UNIONuser_testNULLrefuser_idx_login_iduser_idx_login_id203const1100NULL

explain关注点

重点要关注如下几列:

列名备注
type本次查询表联接类型,从这里可以看到本次查询大概的效率。
key最终选择的索引,如果没有索引的话,本次查询效率通常很差。
key_len本次查询用于结果过滤的索引实际长度。
rows预计需要扫描的记录数,预计需要扫描的记录数越小越好。
Extra额外附加信息,主要确认是否出现 Using filesort、Using temporary 这两种情况。

 其中,type包含以下几种结果,从上之下依次是最差到最好:

类型备注
ALL执行full table scan,这是最差的一种方式。
index执行full index scan,并且可以通过索引完成结果扫描并且直接从索引中取的想要的结果数据,也就是可以避免回表,比ALL略好,因为索引文件通常比全部数据要来的小。
range利用索引进行范围查询,比index略好。
index_subquery子查询中可以用到索引。
unique_subquery子查询中可以用到唯一索引,效率比 index_subquery 更高些。
index_merge可以利用index merge特性用到多个索引,提高查询效率。
ref_or_null表连接类型是ref,但进行扫描的索引列中可能包含NULL值。
fulltext全文检索。
ref基于索引的等值查询,或者表间等值连接。
eq_ref表连接时基于主键或非NULL的唯一索引完成扫描,比ref略好。
const基于主键或唯一索引唯一值查询,最多返回一条结果,比eq_ref略好。
system查询对象表只有一行数据,这是最好的情况。

MySQL中的explain解析_杨 戬的博客-CSDN博客

索引失效的情况及解决(超详细)_zyy_demon的博客-CSDN博客

  • 1
    点赞
  • 10
    收藏
    觉得还不错? 一键收藏
  • 2
    评论
索引失效在数据库查询中是一个常见的问题。当索引无法有效地帮助查询时,查询性能可能会受到影响。有几个常见的原因可能导致索引失效: 1. 数据不匹配:如果查询条件与索引列上的数据类型不匹配,或者使用了不匹配的字符集或排序规则,索引可能会失效。确保查询条件与索引列的数据类型和字符集匹配。 2. 使用函数或表达式:如果在查询条件使用了函数或表达式,索引可能无法生效。因为函数和表达式的结果无法被索引存储,系统将不得不扫描整个表来计算这些结果。 3. 索引列顺序不匹配:在复合索引中,索引列的顺序非常重要。如果查询条件中的列顺序与复合索引不匹配,索引可能会失效。确保查询条件中的列顺序与复合索引的列顺序相同。 4. 数据分布不均匀:如果索引列上的数据分布不均匀,即某些值的数量非常大,而其他值的数量非常小,索引可能会失效。这种情况下,优化器可能会选择全表扫描而不是使用索引。 5. 数据量太小:对于一些小规模的表,使用索引可能没有明显的性能提升。在这种情况下,优化器可能会选择全表扫描。如果表很小,考虑是否需要使用索引。 6. 索引统计信息过时:索引统计信息用于优化查询的执行计划。如果统计信息过时或不准确,优化器可能会做出错误的决策,导致索引失效。定期更新索引统计信息是很重要的。 以上只是一些可能导致索引失效的常见原因,具体情况可能因数据库配置、查询语句和数据特性而异。如果遇到索引失效的问题,可以通过查看执行计划、优化查询语句、更新统计信息等手段来解决问题。
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值