关于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
以上为个人经验,希望能给大家一个参考,也希望大家多多支持我们。
相关推荐
-
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(
随机推荐
- 开通虚拟主机时提示Server.CreateObject失败的解决办法
- centos系统升级python 2.7.3
- java单例模式使用详解
- oracle 实际值超过数据库某个字段指定长度报错解决
- PHP制作图形验证码代码分享
- php实现登陆模块功能示例
- android获取音乐文件的内置专辑图片实现思路及代码
- python实现list元素按关键字相加减的方法示例
- delphi 正弦曲线图
- C# 类的声明详解
- Javascript中的关键字和保留字整理
- PHP5.2中date()函数显示时间与北京时间相差8小时的解决办法
- C语言实现字符串匹配KMP算法
- VC++实现View内容保存为图片的方法
- javascipt基础内容--需要注意的细节
- Node.js中process模块常用的属性和方法
- 浅谈c++ vector和map的遍历和删除对象
- 浅析Java中Map与HashMap,Hashtable,HashSet的区别
- PHP中的switch语句的用法实例详解
- 完美解决令人抓狂的zend studio 7代码提示(content Assist)速度慢的问题