开发者

关于mysql left join 查询慢时间长的踩坑总结

开发者 https://www.devze.com 2022-12-11 13:24 出处:网络 作者: Haocaibo
目录问题背景问题分析及处理1、EXPLAIN 命令对 SELECT 语句进行分析2、新编程客栈增索引3、修改索引字段类型一致渣渣总结问题背景
目录
  • 问题背景
  • 问题分析及处理
    • 1、EXPLAIN 命令对 SELECT 语句进行分析
    • 2、新编程客栈增索引
    • 3、修改索引字段类型一致
  • 渣渣总结

    问题背景

    两张表一张是用户表a(主键是int类型),一张是用户具体信息表b(用户表id字段是varchar类型)。

    因为要显示用户及用户信息,所以需要关联查询,但发现left join后查询缓慢,耗时太长。用户表数据2万左右。

    关于mysql left join 查询慢时间长的踩坑总结

    问题分析及开发者_Hbase处理

    1、EXPLAIN 命令对 SELECT 语句进行分析

    关于mysql left join 查询慢时间长的踩坑总结

    type 字段提供了判断查询是否高效的重要依据依据. 通过 type 字段, 我们判断此次查js询是 全表扫描 还是 索引扫描 等.

    ALL: 表示全表扫描, 这个类型的查询是性能最差的查询之一.

    通常来说, 我们的查询不应该出现 ALL 类型的查询, 因为这样的查询在数据量大的情况下, 对数据库的性能是巨大的灾难. 如一个查询是 ALL 类型查询, 那么一般来说可以对相应的字段添加索引来避免.

    2、新增索引

    因为发现表b字段之前并没有建索引。

    alter table a add index idx_mbrID (mbrID);

    再次Explain分析

    关于mysql left join 查询慢时间长的踩坑总结

    发现type变为了ref,根据不同的 type 类型的性能rvhXBfzk关系(

    javascript
    ALL < index < range ~ index_merge < ref < eq_ref < const < system

    )比较后感觉可以了,于是执行查询。

    关于mysql left join 查询慢时间长的踩坑总结

    3、修改索引字段类型一致

    执行查询后发现执行速度并未优化,仔细看之前同事设计的表,发现索引类型字段不一致,于是修改为varchar 为int后再次查询发现查询速度明显提升。

    即使之前Java代码里面写的string,数据库改为int目前测试可正常使用

    关于mysql left join 查询慢时间长的踩坑总结

    渣渣总结

    解决完问题后,翻起了开发手册,发现索引规约明确强制join时数据类型必须一致,被关联字段必须有索引!!!

    关于mysql left join 查询慢时间长的踩坑总结

    关于mysql left join 查询慢时间长的踩坑总结

    关于Explain用法参考rvhXBfzk

    https://www.jb51.net/article/167406.htm

    以上为个人经验,希望能给大家一个参考,也希望大家多多支持我们。 

    0

    精彩评论

    暂无评论...
    验证码 换一张
    取 消

    关注公众号