乾貨分享：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，果不其然，除了主鍵索引，一個索引都沒有創建（爲這臺年老失修的服務器感到驕傲，它居然扛了那麼久授小弟一拜）。