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

目录
  • 问题背景
  • 问题分析及处理
    • 1、EXPLAIN 命令对 SELECT 语句进行分析
    • 2、新增索引
    • 3、修改索引字段类型一致
  • 渣渣总结

问题背景

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

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

问题分析及处理

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

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

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

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

2、新增索引

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

alter table a add index idx_mbrID (mbrID);

再次Explain分析

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

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

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

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

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

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

渣渣总结

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

关于Explain用法参考

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

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

(0)

相关推荐

  • MySQL联表查询基本操作之left-join常见的坑

    概述 对于中小体量的项目而言,联表查询是再常见不过的操作了,尤其是在做报表的时候.然而校对数据的时候,您发现坑了吗?本篇文章就 mysql 常用联表查询复现常见的坑. 基础环境 建表语句 DROP TABLE IF EXISTS `role`; CREATE TABLE `role` ( `id` int(11) NOT NULL AUTO_INCREMENT, `role_name` VARCHAR(50) DEFAULT NULL COMMENT '角色名', PRIMARY KEY (`i

  • 总结12个MySQL慢查询的原因分析

    目录 1. SQL 没加索引 2. SQL 索引不生效 2.1 隐式的类型转换,索引失效 2.2 查询条件包含 or,可能导致索引失效 2.3. like 通配符可能导致索引失效 2.5 在索引列上使用 mysql 的内置函数 2.6 对索引进行列运算(如,+.-.*./), 索引不生效 2.7 索引字段上使用(!= 或者 < >),索引可能失效 2.8 索引字段上使用 is null, is not null,索引可能失效 2.9 左右连接,关联的字段编码格式不一样 2.10 优化器选错了索

  • MySQL查询优化之查询慢原因和解决技巧

    在做开发的朋友特别是和mysql有接触的朋友会碰到有时mysql查询很慢,当然我指的是大数据量百万千万级了,不是几十条了, 下面我们来看看解决查询慢的办法 会经常发现开发人员查一下没用索引的语句或者没有limit n的语句,这些没语句会对数据库造成很大的影响,例如一个几千万条记录的大表要全部扫描,或者是不停的做filesort,对数据库和服务器造成io影响等.这是镜像库上面的情况. 而到了线上库,除了出现没有索引的语句,没有用limit的语句,还多了一个情况,mysql连接数过多的问题.说到这里

  • MySQL慢查询的坑

    一条慢查询会造成什么后果?年轻时,我一直觉得不就是返回数据会慢一些么,用户体验变差?其实远远不止,我经历过几次线上事故,有一次就是由一条SQL慢查询导致的. 记得那是一条查询SQL,数据量万级时还保持在0.2秒内,随着某一段时间数据猛增,耗时一度达到了2-3秒!没有命中索引,导致全表扫描.explain 中extra显示:Using where; Using temporary; Using filesort,被迫使用了临时表排序,由于是高频查询,并发一起来很快就把DB线程池打满了,导致大量查询

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

    目录 问题背景 问题分析及处理 1.EXPLAIN 命令对 SELECT 语句进行分析 2.新增索引 3.修改索引字段类型一致 渣渣总结 问题背景 两张表一张是用户表a(主键是int类型),一张是用户具体信息表b(用户表id字段是varchar类型). 因为要显示用户及用户信息,所以需要关联查询,但发现left join后查询缓慢,耗时太长.用户表数据2万左右. 问题分析及处理 1.EXPLAIN 命令对 SELECT 语句进行分析 type 字段提供了判断查询是否高效的重要依据依据. 通过 t

  • MySQL中join查询的深入探究

    目录 前引 索引对 join 查询的影响 数据准备 有索引查询过程 无索引查询过程 了解 Block Nested-Loop Join Block Nested-Loop Join查询过程 Join_buffer 如何正确的写出 join 查询 驱动表的选择 什么是小表 结论: 前引 相信大家 MySQL 都用了很久了,各种 join 查询天天都在写,但是 join 查询到底是怎么查的,怎么写才是最正确的,今天我就和大家一起学习探讨一下 索引对 join 查询的影响 数据准备 假设有两张表 t1

  • Mysql连接join查询原理知识点

    Mysql连接(join)查询 1.基本概念 将两个表的每一行,以"两两横向对接"的方式,所得到的所有行的结果. 假设: 表A有n1行,m1列: 表B有n2行,m2列: 则表A和表B"对接"之后,就会有: n1*n2行: m1+m2列. 2.则他们对接(连接)之后的结果类似这样: 3.连接查询基本形式: from  表1  [连接方式] join  表2  [on连接条件]连接查询基本形式: from  表1  [连接方式] join  表2  [on连接条件] 1

  • 解析MySQL join查询的原理

    MySQL用Nested-Loop Join算法实现join查询 区分驱动表和被驱动表,以驱动表的结果集为循环的基础,访问被驱动表过滤数据,然后合并结果,驱动表在外循环.被驱动表在内循环.如果还有第三张参与join查询的表,则以合并的结果为驱动表,第三张表作为被驱动表,以此类推. left join中的左表是驱动表.右表是被驱动表,right join刚好相反. Nested-Loop Join有三种实现 SNLJ Simple Nested-Loop Join 假设A是驱动表,B是被驱动表.

  • 详解Mysql两表 join 查询方式

    目录 一.SQL基本语法格式 二.3种join方式 1. left join(左连接) 2. right join(右连接) 3. inner join(内连接) 4. 在理解上面的三种join下,查询(A -  A∩B) 5. 查询 ( B - A∩B ) 6. 查询(A∪B - A∩B) 7. 查询 AUB 一.SQL基本语法格式 SELECT DISTINCT < select_list > FROM < left_table > < join_type > JO

  • MySQL启用慢查询日志记录方法

    在MySQL中,慢查询的界定时间是由MySQL内置参数变量long_query_time来指定的,其默认值为10(单位:秒),我们可以通过show variables like 'long_query_time';指令来查看该参数变量的信息: long_query_time的默认值为10秒 不过,在程序开发过程中,我们认为慢速查询的界定时间并没有10秒这么长,依据不同项目的不同需求,我们一般将慢查询的界定时间设定为1~5秒之间.我们可以使用指令set long_query_time = 秒数来设

  • 深入分析MySQL Sending data查询慢问题

    通过一个实例给大家分享了MySQL Sending data表查询慢问题解决办法. 最近在代码优化中,发现了一条sql语句非常的慢,于是就用各种方法进行排查,最后终于找到了原因. 一.事故现场 SELECT og.goods_barcode, og.color_id, og.size_id, SUM(og.goods_number) AS sold_number FROM order o LEFT JOIN order_goods og ON o.order_id = og.order_id W

  • MySQL如何优化查询速度

    前面章节我们介绍了如何选择优化的数据类型.如何高效的使用索引,这些对于高性能的MySQL来说是必不可少的. 但这些还完全不够,还需要合理的设计查询. 如果查询写的很糟糕,即使表结构再合理.索引再合适,也是无法实现高性能的. 谈到MySQL性能优化,查询优化作为优化的源头,它也是最能体现一个系统是否更快. 本章以及接下来的几章将会着重讲解关于查询性能优化的内容,从中会介绍一些查询优化的技巧,帮助大家更深刻地理解MySQL如何真正地执行查询.究竟慢在哪里.如何让其快起来,并明白高效和低效的原因何在,

  • MySQL优化总结-查询总条数

    1.COUNT(*)和COUNT(COL) COUNT(*)通常是对主键进行索引扫描,而COUNT(COL)就不一定了,另外前者是统计表中的所有符合的纪录总数,而后者是计算表中所有符合的COL的纪录数.还有有区别的. 优化总结,对于MyISAM表来说: 1.任何情况下SELECT COUNT(*) FROM tablename是最优选择: 2.尽量减少SELECT COUNT(*) FROMtablename WHERE COL = 'value' 这种查询: 3.杜绝SELECT COUNT(

随机推荐