手机版
你好,游客 登录 注册 搜索
背景:
阅读新闻

MySQL 5.6.38优化实例一则

[日期:2018-01-05] 来源:Linux社区  作者:liuhuang9496 [字体: ]

导读:在日常的MySQL的SQL语句优化工作中,总会遇到了各种各样的问题。今天就是遇到了一个比较诡异的问题,在这里记录下来方便自己的记忆。

    MySQL版本信息: MySQL 5.6.38

  1. SQL语句(其中的关键字信息已经做脱敏处理):

SELECT id, name, headurl, intro, gender, location, job, birthday, source,created_at FROM user  WHERE name LIKE '%name%' ORDER BY created_at DESC LIMIT 0100;

  2. 表user的表结构:

MySQL 5.6.38优化

  3. SQL的执行计划和profile信息以及执行耗时:

MySQL 5.6.38优化  4.优化思路:在执行计划中可以看得到SQL语句由于是模糊查询所以并没有使用索引,并且在执行SQL之后可以明显的看出在创建排序索引上面耗费了99%以上的时间,我们在看整个的SQL语句,只有在字段created_at上面有做排序操作,所以按照优化思路那么我们就需要在created_at这个字段上面创建索引。创建索引之后的表结构:MySQL 5.6.38优化

红框就是添加的索引信息。

  5.修改之后的SQL的执行计划和profile以及耗时信息:

MySQL 5.6.38优化

MySQL 5.6.38优化

    在上面的执行计划进行比对我们可以很明显的看出来,返回的数据由450w减少到了100行,数据量大大的减少了;但是在执行SQL之后发现耗时居然更长了使用了6s多,并且分析profile的时候发现在sending data耗时花费了6.6s的样子,在这里解释一下 sending data耗时指的的是从引擎层发送数据到server层或者是client层。

    发现这种情况我感到很吃惊,我并不知道发生了什么事情导致这种结果。在多方查询无果之后我之后请教我的一个师兄,经过我详细的描述和实验,他告诉我:主要是由于在where条件过滤和排序的时候走索引没有查询到任何的结果导致mysql获取查询所有的索引然后在去回表进行全局扫描;在没有添加的索引的情况下,SQL直接就回回表不会进行全部的索引扫描。

    为了验证这个结果,我更改了where条件,在没有添加created_at这个字段索引的情况下进行对比情况:

没有添加索引的耗时:

100 rows in set (2.53 sec)

添加索引的耗时:

100 rows in set (0.16 sec)

可以很明显的看到添加索引之后 速度提高了一大堆,并且这个是有查询结果的。

 

 

linux
相关资讯       MySQL优化 
本文评论   查看全部评论 (0)
表情: 表情 姓名: 字数

       

评论声明
  • 尊重网上道德,遵守中华人民共和国的各项有关法律法规
  • 承担一切因您的行为而直接或间接导致的民事或刑事法律责任
  • 本站管理人员有权保留或删除其管辖留言中的任意内容
  • 本站有权在网站内转载或引用您的评论
  • 参与本评论即表明您已经阅读并接受上述条款