mysql左关联不走索引的一个问题的排查过程及思考

最新推荐文章于 2025-09-04 11:31:15 发布
原创 最新推荐文章于 2025-09-04 11:31:15 发布 · 3.5k 阅读 · 4
文章标签：

#mysql

本文记录了一个MySQL查询慢的问题，原因是两个表关联字段字符集不一致导致索引未被使用。通过调整字段字符集至一致，成功解决了查询效率问题。排查过程中尝试了修改SQL语句，包括使用等连接和调整表连接顺序，发现这些方法只能暂时解决问题，最终解决关键在于字段字符集的一致性。

今天遇到一个mysql查询不走索引的情况,记录一下排查过程及解决办法
Mysql版本 5.6 5.7

错误情况

两表关联,两表数据量不超过10w,查询速度极慢,基本约等于查不出来.

测试:
表1 user表 数据量10w
表2 user_role表 数据量10w

查询语句

select * from user_role a left join user b on a.user_no = b.user_no

排查过程

查看执行过程
image.png
发现a表并没有走索引,全表扫描
而b表的Extra里的信息显示使用了BNL算法,效率很低(相较于索引) 感兴趣的可以搜一下Using join buffer (Block Nested Loop)

  1. 排查关联条件字段类型 一致
  2. 排查索引是否正确 没问题
最低0.47元/天 解锁文章
MySQL 索引进阶：聚簇索引与非聚簇索引底层差异 + 索引失效终极排查（含执行计划深度解析）
网络工程师｜十多年企业级运维实战｜精通 ‌BGP、OSPF、VLAN、SDN、MPLS、ACL、NetFlow、SNMP、
04-18 5
MySQL索引深度解析：聚簇与非聚簇索引底层差异及索引失效排查 摘要： 本文深入剖析MySQL中聚簇索引与非聚簇索引的核心差异，揭示二者在存储结构、查询效率和维护成本上的本质区别。聚簇索引将数据与索引合为一体，而非聚簇索引需通过回表查询数据。同时，文章重点分析了生产环境中常见的索引失效场景，包括隐式类型转换、范围查询导致的联合索引失效等问题，并提供了底层原理分析和解决方案。通过执行计划深度解析，帮助开发者精准识别和解决索引性能问题，避免常见的索引使用误区。
查一次left join没有走索引以及原因
热门推荐
hello world
06-10 4万+
线上有个查询sql，原来是inner join 查询没有问题，后来应业务要求改成left join之后， 查询时间就暴涨了 需要长达24s 通过explain分析，发现订单表没有走索引 ，分析之后解决了，记录下来。 为了简洁起见，这里就将无关的查询字段都用* 具体sql如下 SELECT * from t_item_detail a left join t_order_detail d ...
【MySQL】MySQL不走索引的情况分析
DreamSun的博客
08-13 1343
未建立索引当数据表没有设计相关索引时，查询会扫描全表。sql复制代码create table test_tempexplain建议查询频繁是数据表字段增加合适的索引。查询结果集是原表中的大部分数据当数据库查询命中索引时，数据库会首先利用索引列的值定位到对应的数据节点。这个数据节点上记录了对应数据行的行标识符（Row Identifier）。然而，如果查询需要获取该行其他列的数据，就需要进行回表操作。
MySQL不走索引的情况分析
FirstMrRight的博客
08-11 1675
innodb表的统计信息并不是实时统计更新，如果统计信息和实际的索引信息差异很大，就会导致优化器计算各个索引成本后，做出非预期的选择。出现这种现象的场景是：当有大量数据在短时间内落库时，Innodb还没更新统计相关信息，此时来了一个查询，MySQL会基于历史数据做出错误的判断：当前表数据量少，不走索引更高效。回表操作可能会增加额外的磁盘访问和数据检索的开销，因此，在某些情况下，当MySQL判断回表所需的资源大于直接扫描全表时，它可能选择不走索引，而是执行全表扫描。查询频繁是数据表字段增加合适的索引。
博客摘录「 mysql的left join索引没_left join 没有走索引原因分析」2023年4月10日
m0_50272029的博客
04-10 558
今天看一条 SQL 的执行计划时候 type 为 index还以为 left join 的时候走了索引。但是 rows 的数据显示是走了全表扫描。奇怪了，而且该字段也是建了索引。
mysql 表关联之后索引失效的原因排查
zhaofuqiangmycomm的博客
05-29 5128
1、两表关联使用的条件字段中字段的长度是否是一致的 2、两表关联使用的条件字段中字段的编码是否是一致的 3，更本就没用到关联表中的字段去查询 今天我发现的问题就是第三个， 客户信息36万，中间表62万，关联了却没用到中间表的城市id去查导致没有用到索引 优化之后我的分页查询是这样的 if("2".equals(customer.getSourceType()) &&customer.getHoHouseCustomer()!=null &&Str
MySQL 慢SQL的排查分析及无法匹配索引的情况
rachel_2016的博客
06-03 940
1、SQL ordered by Rows Examined Average平均扫描记录数高，但平均返回（Rows Send avg）少说明SQL效率存在问题。复合索引是从第一个索引列开始，从左到右依次匹配，一旦某个字段不能匹配，便停止匹配，后边的索引字段不会再匹配，即使覆盖了其他索引列也无法利用索引。3、SQL ordered by Elapsed Time Average SQL执行时间超过1秒的都需要关注。可以关注 扫描数据量大的SQL，通常伴随着CPU的升高。5.查询条件使用负向查询条件:NOT!
MySQL备份问题排查和思考
uuqaz的博客
04-12 1011
1. 背景 2. 疑点 3. 问题分析 4. 问题定位 5. checking permissions的疑惑 6. 探索优化思路 7. 补充：关于几个timeout参数生效点 1. 背景 行内数据库备份在使用某备份软件，使用的数据库版本MySQL 8.0社区版，全备使用mysqldump进行，DBA早上巡检发现有一套数据库全备份失败，心里一疙瘩怎么回事呢？来看看如下报错 [mysqldump: Error: 'Lost connection to MySQL server during q
mysql哪些查询情况不走索引
得塔云的博客
12-02 2865
在MySQL中，并不是你建立了索引，并且你在SQL中使用到了该列，MySQL就肯定会使用到那些索引的，有一些情况很可能在你不知不觉中，你就“成功的避开了”MySQL的所有索引。 1、索引列参与计算，不走索引 SELECT `username` FROM `t_user` WHERE age=20;-- 会使用索引 SELECT `username` FROM `t_user` WHERE age+10=30;-- 不会使用索引！！因为所有索引列参与了计算 SELECT `username` FROM
计一次mysql left join 查询不走索引的问题
一个到老才知道分享的人的博客
10-26 7738
前言 本地有两张表 alarm闹钟表和alarm_order闹钟订单表 在alarm_order订单表中有alarm_id建立了索引，但是发现在left join查询的时候没有走索引查询，使用了全文搜索 问题分析 乍一看，sql语句似乎并没有问题 1、首先，来观察下两张表的字符类型是否相同 发现两张表的字符类型确实不一样，随后把表1改为utf8，再次查询发现依旧不起作用 2、最后发现可能是alarm_order表中的alarm_id的基数太小了，mysql判断全文搜索速度要快，则进行全文搜索。后发
mysql left join没有走索引，确定on的字段都是有索引
chwlallen的专栏
07-06 955
今天在开发过程中，用到mysql 的left join，两个表数据都不多，都不超过2万左右条记录。以为是个很轻松的活，select a.*,b.* from a left join b on a.id=b.pid。一运行，傻眼了，卡住了半天没有结果，最后超时了。仔细看了这两个表，a.id还是主键，b.pid也有建索引，百思不得其解，搜了一通，不得要领。继续搜，皇天不负有心人，找到答案原来是要求join on的字段类型要一致才会走索引。a.id主键类型为int，b.pid为varchar。
MySQL 索引失效场景
u014520797的专栏
03-31 1003
1、对索引列运算（如，+、-、*、/），索引失效。 2、查询条件包含or，可能导致索引失效 3、like通配符可能导致索引失效（左侧有%）。 4、左连接查询或者右连接查询查询关联的字段编码格式不一样，可能导致索引失效。 5、在索引列上使用mysql的内置函数，索引失效。 6、索引字段上使用isnull，isnotnull，可能导致索引失效。 7、如何字段类型是字符串，where时一定用引号括起来，否则索引失效 8、mysql估计使用全表扫描要比使用索引快,则不使用索引。 9、联合索引，...
mysql left join 后索引不起作用
java_chegnxuyuan的博客
05-23 2533
今天在优化sql时，发现左连接的表中的索引一直没有使用到 结果发现：当left join的两个字段的字符集和排序规则不想同时，会出现索引失效的情况。 ...
MySQL 全库备份迁移后索引失效问题深度解析与解决
最新发布
菜鸟学习成功之路
09-04 1075
MySQL全库迁移后索引失效问题解析与解决 在MySQL全库迁移后，发现stock_in_detail表等多个业务表查询性能急剧下降，EXPLAIN分析显示优化器未使用索引而采用全表扫描。通过SHOW INDEX检查发现，索引虽存在但Cardinality（区分度估算值）均为0，导致优化器误判索引效率。 问题根源：迁移后未自动更新索引统计信息。解决方案：执行ANALYZE TABLE stock_in_detail手动更新统计信息，Cardinality恢复为正常值（如主键80766、in_id11204）
面试突击：什么情况会导致 MySQL 索引失效？
m0_71777195的博客
07-04 901
为了验证 MySQL 中哪些情况下会导致索引失效，我们可以借助 explain 执行计划来分析索引失效的具体场景。explain 使用如下，只需要在查询的 SQL 前面添加上 explain 关键字即可，如下图所示：而以上查询结果的列中，我们最主要观察 key 这一列，key 这一列表示实际使用的索引，如果为 NULL 则表示未使用索引，反之则使用了索引。以上所有结果列说明如下：其中最重要的就是 type 字段，type 值类型如下：all — 扫描全表数据；index — 遍历索引；range — 索引范
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

zhang.yao

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值