加入收藏 | 设为首页 | 会员中心 | 我要投稿 李大同 (https://www.lidatong.com.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 站长学院 > MySql教程 > 正文

一次mysql优化经历

发布时间:2020-12-12 02:18:21 所属栏目:MySql教程 来源:网络整理
导读:某日运维突然说无线终端的频道页接口访问量很大,memcache缓存扛不过来,导致mysql并发查询量太大,导致服务器不停地宕机,只能不停地重启机器。遗憾的是运维并没有告诉mysql查询量具体有多大【无量化,比如一秒多少个查询】。 针对这个问题,有同事建议改了

某日运维突然说无线终端的频道页接口访问量很大,memcache缓存扛不过来,导致mysql并发查询量太大,导致服务器不停地宕机,只能不停地重启机器。遗憾的是运维并没有告诉mysql查询量具体有多大【无量化,比如一秒多少个查询…】。

针对这个问题,有同事建议改了mysql+memcache的架构,采用redis存储更佳。但是问题的真正原因是什么呢?mysql一秒钟扛几百个并发查询应该是可以的吧?带着疑问,我让运维给出慢查询log。

Oh,my god…慢查询记录太多,都是一秒钟以上的,但是基本上是同一条语句的查询。explain一下:

Sql语句中有order by zj_lastupdate,明明在这个字段上建立了索引的,但为什么没用呢【这个表上建立了太多联合索引,以致zj_lastupdate被无视了】,所以导致这条查询使用了临时表【using temporary】和文件排序【usingfilesort】。

 解决的办法是在sql语句中加上use index(zj_lastupdate),提醒mysql引擎使用指定索引字段。再explain一下:

显然,这次查询引擎会使用zj_lastupdate了。

优化的效果是相当的明显,从之前的1.5秒降到0.015秒,百倍的性能提升。当然,这个问题解决之后,也就没有出现宕机的情形了,我们也没有改架构。

 

再说一个mysql优化经历,2表相连,一对一的关系,优化之前的sql语句大概是selectdistinct(movieid) as id…,explain的结果是:

显然,一对一关系的表,无需添加distinct关键字【算是画蛇添足吧】,去掉之后,再explain:

优化前后性能提升10倍左右。

 

Mysql的查询优化有很多基础理论,可以从查询语句,表结构【分表,字段冗余】,字段类型,索引,存储引擎,缓存,系统内核参数,磁盘IO等方面考虑,但是很重要的一点是写出具体的sql语句,针对这特定的语句进行具体的优化,当然前提是保证结果是准确的。

 

 

 

 

(编辑:李大同)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    推荐文章
      热点阅读