干货分享：MySQL之化险为夷的【钻石】抢购风暴

抢购钻石不稀奇，稀奇的是有钱赚不到，事情发生在2015年5月20日，大好的日子天然少不了商家的参与。便可为您还原现场，解决思路献给各位，请欣赏Show Time,everybody~

一、优化原由及工做准备

　　2014年5月20日下午三点四十接到对方不肯意透漏姓名的“王大锤”领导的电话，对方火急火燎的仅提供了网站访问慢一条信息，当时博主那个内心一万只XX奔腾而过，俗话说的好，酒肉穿肠过，拿人钱财必替人消灾。

　　对博主来讲网站访问慢，首先不能乱了阵脚，先想到的就是看web、先看静态，若是静态ok就看动态，若是还不ok就看存储，再不行就看访问DB时长是否正常。此时缘由就能够定位了。不会再有其余缘由了。若是你太菜，那你能够把个人思路背过，相信对你来讲是一个很好的帮助，此时一边与对方沟通更可能多的得到信息，但是对方一点都不懂，只好无能为力，与对方协商相关责任制后当即登陆服务器（本人兼职XX钻世界集团技术顾问一职）。

　　凭借我的经验查看web负载并不高，静态访问速度正常，因为线上活动正在进行，晚一分钟对商家便是损失，此时没法进行许多系统的排查，直接则判断是不是后端DB的问题？随登陆DB查看负载。发现DB负载不正常，就没有进行其余的判断（什么IO看一下啊，内存看一下啊，网卡看一下啊，再看公司都倒闭了。），紧急恢复问题就是最大化的恢复问题，找到问题所在即刻解决问题。此时判断数据库有慢查询。

1 ================2015年5月20日 13:38:08日负载以下：================
2 [lcp@ZCdb01 ~]$ uptime
3 13:50:36 up 122 days, 21:51, 1 user, load average: 6.44, 5.76, 5.38
4 
5 [lcp@ZCdb01 ~]$ uptime
6 13:51:38 up 122 days, 21:22, 1 user, load average: 8.01, 6.30, 5.58

二、判断问题所在　

　随登陆数据库show full processlist;此工具运维人员必备，干了几年的运维别说你不会。不会的话看了个人博客也应该会了。

连抓了两遍以后发现，这一堆东西不动啊，前面排着的update被锁定，想写还写不进去。select过多，读也读不出来。

 

1 mysql> show processlist;
2 +----+-------------+-----------+------+---------+------+-----------------------------------------------------------------------------+------------------+

三、定位待优化语句

再返回来看后面的查询语句是经过三个条件进行查询的。因而定位了待优化的语句也就是下方的select出现次数最多的语句

　　　　　　　　　　　　　　　　　　　　　　　　　↑↑↑查询语句如上↑↑↑

　　随后抓出一条命令explain，屡次确认后加SQL_NO_CACHE不让其走缓存再反复确认，最终判断次语句没有创建索引或走索引，共查阅7万3千多条数据耗时惊人。

1 mysql> select SQL_NO_CACHE id from **_**_detail where ader='**_**-jazz_flash' and dateline='**_**' and pos='**_**';

　　此时看到可能走的索引和索引都是不存在的。独立奔跑在七万多条语句中

1 possible_keys：NULL
2 
3 　　　　    key：NULL
4 
5 　　　　  rows：71328  #接近全盘扫描

 　　我记得这台机器是戴尔服务器2850很老的一台服务器，但这很明显不是硬件问题，随问对方的主管，有没有人对这台机器进行优化，一边电话询问一边进行查看，去证明本身的想法，使用show查看表结构show create table **_**_detai\G，果不其然，除了主键索引，一个索引都没有创建（为这台年老失修的服务器感到骄傲，它居然扛了那么久授小弟一拜）。