如果出現了性能問題，則可以進行分析：
1、是不是有sql語句卡住了？
這是出現比較多的情況，如果數據庫是采用myisam，那麼有可能有一個寫入的線程會把數據表給鎖定了，如果這條語句不結束，則其它語句也無法運行。
查看processlist裡的time這一項，看看有沒有執行時間很長的語句，要留意這些語句。
2、大量相同的sql語句正在執行
如果出現這種情況，則有可能是該sql語句執行的效率低下，同樣要留意這些語句。
然後把你所懷疑的語句統統集合一下，用desc（explain）來檢查這些語句。
首先看看一個正常的desc輸出：
MySQL> desc select * from imgs where imgid=1651768337;
+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | extra |
+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------+
| 1 | simple | imgs | const | primary | primary | 8 | const | 1 | |
+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------+
1 row in set (0.00 sec)
注意key、rows和extra這三項，這條語句返回的結果說明了該sql會使用primary主鍵索引來查詢，結果集數量為1條，extra沒有顯示，證明沒有用到排序或其他操作。由此結果可以推斷，MySQL會從索引中查詢imgid=1651768337這條記錄，然後再到真實表中取出所有字段，是很簡單的操作。
key是指明當前sql會使用的索引，MySQL執行一條簡單語句時只能使用到一條索引，注意這個限制；rows是返回的結果集大小，結果集就是使用該索引進行一次搜索的所有匹配結果；extra一般會顯示查詢和排序的方式，。
如果沒有使用到key，或者rows很大而用到了filesort排序，一般都會影響到效率，例如：
MySQL> desc select * from imgs where userid="7mini" order by clicks desc limit 10;
+----+-------------+-------+------+---------------+------+---------+------+-------+-----------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | extra |
+----+-------------+-------+------+---------------+------+---------+------+-------+-----------------------------+
| 1 | simple | imgs | all | null | null | null | null | 12506 | using where; using filesort |
+----+-------------+-------+------+---------------+------+---------+------+-------+-----------------------------+
1 row in set (0.00 sec)
這條sql結果集會有12506條，用到了filesort，所以執行起來會非常消耗效率的。這時MySQL執行時會把整個表掃描一遍，一條一條去找到匹配userid="7mini"的記錄，然後還要對這些記錄的clicks進行一次排序，效率可想而知。真實執行時如果發現還比較快的話，那是因為服務器內存還足夠將12506條比較短小的記錄全部讀入內存，所以還比較快，但是並發多起來或者表大起來的話，效率問題就嚴重了。
