讓天下沒有難用的資料庫 » 關於RDS例項CPU超過100%的分析
經常聽見使用者說自己的rds例項cpu超過100%，通常這種情況都是由於sql效能問題導致的,下面我用一則案例來分析：
使用者例項zuowenwang反映cpu超過100%，例項偶爾出現卡住的現象；
1.原理：cpu消耗過大通常情況下都是有慢sql造成的，這裡的慢sql包括全表掃描，掃描資料量過大，記憶體排序，磁碟排序，鎖爭用等待等；
2.表現現象sql執行狀態為：sending data，Copying to tmp table，Copying to tmp table on disk，Sorting result，locked;
3.解決方法：使用者可以登入到rds，通過show processlist檢視當前正在執行的sql，當執行完show processlist後出現大量的語句，通常其狀態出現sending data，Copying to tmp table，Copying to tmp table on disk，Sorting result, Using filesort 都是sql有效能問題；
A.sending data表示：sql正在從表中查詢資料，如果查詢條件沒有適當的索引，則會導致sql執行時間過長；
B.Copying to tmp table on disk：出現這種狀態，通常情況下是由於臨時結果集太大，超過了資料庫規定的臨時記憶體大小，需要拷貝臨時結果集到磁碟上，這個時候需要使用者對sql進行優化；
C.Sorting result, Using filesort：出現這種狀態，表示sql正在執行排序操作，排序操作都會引起較多的cpu消耗，通常的優化方法會新增適當的索引來消除排序，或者縮小排序的結果集；
通過show processlist發現如下sql：
Sql A.
| 2815961 | sanwenba | 10.241.142.197:55190 | sanwenba | Query | 0 | Sorting RESULT | SELECT z.aid,z.subject FROM www_zuowen z RIGHT JOIN www_zuowenaddviews za ON za.aid=z.aid ORDER BY za.viewnum DESC LIMIT 10;
效能sql：
SELECT z.aid,z.subject FROM www_zuowen z RIGHT JOIN www_zuowenaddviews za ONza.aid=z.aid ORDER BY za.viewnum DESC LIMIT 10;
用explain 檢視執行計劃：
[email protected] 10:00:54>explain SELECT z.aid,z.subject FROM www_zuowen z RIGHT JOIN www_zuowenaddviews za ON za.aid=z.aid ORDER BY za.viewnum DESC LIMIT 10; +----+-------------+-------+--------+---------------+---------+---------+-----------------+------ | id | select_type | TABLE | TYPE | possible_keys | KEY | key_len | REF | ROWS | Extra | +----+-------------+-------+--------+---------------+---------+---------+-----------------+------ | 1 | SIMPLE | za | INDEX | NULL | viewnum | 6 | NULL | 537029 | USING INDEX; USING filesort | | 1 | SIMPLE | z | eq_ref | PRIMARY | PRIMARY | 3 | sanwenba.za.aid | 1 | |
新增適當索引消除排序：
[email protected] 10:02:33 ALTER TABLE www_zuowenaddviews ADD INDEX ind_www_zuowenaddviews_viewnum(viewnum); [email protected] 10:03:27explain SELECT z.aid,z.subject FROM www_zuowen z RIGHT JOIN www_zuowenaddviews za ON za.aid=z.aid ORDER BY za.viewnum DESC LIMIT 10; +----+-------------+-------+--------+---------------+--------------------------------+---------+- | id | select_type | TABLE | TYPE | possible_keys | KEY | key_len | REF | ROWS | Extra | +----+-------------+-------+--------+---------------+--------------------------------+---------+- | 1 | SIMPLE | za | INDEX | NULL | ind_www_zuowenaddviews_viewnum | 3 | NULL | 10 | USING INDEX | | 1 | SIMPLE | z | eq_ref | PRIMARY PRIMARY | 3 | sanwenba.za.aid | 1 | | +----+-------------+-------+--------+---------------+--------------------------------+---------+-
Sql B:
| 2825321 | netzuowen | 10.200.120.41:44172 | netzuowen | Query | 2 | Copying TO tmp TABLE ON disk SELECT * FROM `www_article` WHERE 1=1 ORDER BY rand() LIMIT 0,30
這種sql order by rand()同樣也會出現排序;
[email protected] 10:23:55 EXPLAIN SELECT * FROM `www_zuowensearch` WHERE checked = 1 ORDER BY rand() LIMIT 0,10 ; +----+-------------+------------------+------+---------------+--------+---------+-------+------+ | id | select_type | TABLE | TYPE | possible_keys | KEY | key_len | REF | ROWS | Extra| +----+-------------+------------------+------+---------------+--------+---------+-------+------+ | 1 | SIMPLE | www_zuowensearch | REF | newest | newest | 1 | const | 1443 | USING TEMPORARY; USING filesort | +----+-------------+------------------+------+---------------+--------+---------+-------+------+
這種隨機抽取一批記錄的做法效能是很差的，表中的資料量越大，效能就越差：
解決方法如下：
http://www.piaoyi.org/php/MySQL-Order-By-Rand.html
第一種方案，即原始的 Order By Rand() 方法：
$sql=”SELECT * FROM content ORDER BY rand() LIMIT 12″;
$result=mysql_query($sql,$conn);
$n=1;
$rnds=”;
while($row=mysql_fetch_array($result)){
$rnds=$rnds.$n.”. <a href=’show”.$row[‘id’].”-“.strtolower(trim($row[‘title’])).”‘>”.$row[‘title’].”</a><br />\n”;
$n++;
}
3萬條資料查12條隨機記錄，需要0.125秒，隨著資料量的增大，效率越來越低。
第二種方案，改進後的 JOIN 方法：
for($n=1;$n<=12;$n++){
$sql=”SELECT * FROM `content` AS t1
JOIN (SELECT ROUND(RAND() * (SELECT MAX(id) FROM `content`)) AS id) AS t2
WHERE t1.id >= t2.id ORDER BY t1.id ASC LIMIT 1″;
$result=mysql_query($sql,$conn);
$yi=mysql_fetch_array($result);
$rnds = $rnds.$n.”. <a href=’show”.$yi[‘id’].”-“.strtolower(trim($yi[‘title’])).”‘>”.$yi[‘title’].”</a><br />\n”;
}
3萬條資料查12條隨機記錄，需要0.004秒，效率大幅提升，比第一種方案提升了約30倍。缺點：多次select查詢，IO開銷大。
第三種方案，SQL語句先隨機好ID序列，用 IN 查詢（飄易推薦這個用法，IO開銷小，速度最快）：
$sql=”SELECT MAX(id),MIN(id) FROM content”;
$result=mysql_query($sql,$conn);
$yi=mysql_fetch_array($result);
$idmax=$yi[0];
$idmin=$yi[1];
$idlist=”;
for($i=1;$i<=20;$i++){
if($i==1){ $idlist=mt_rand($idmin,$idmax); }
else{ $idlist=$idlist.’,’.mt_rand($idmin,$idmax); }
}
$idlist2=”id,”.$idlist;
$sql=”select * from content where id in ($idlist) order by field($idlist2) LIMIT 0,12″;
$result=mysql_query($sql,$conn);
$n=1;
$rnds=”;
while($row=mysql_fetch_array($result)){
$rnds=$rnds.$n.”. <a href=’show”.$row[‘id’].”-“.strtolower(trim($row[‘title’])).”‘>”.$row[‘title’].”</a><br />\n”;
$n++;
}
3萬條資料查12條隨機記錄，需要0.001秒，效率比第二種方法又提升了4倍左右，比第一種方法提升120倍。注，這裡使用了 order by field($idlist2) 是為了不排序，否則 IN 是自動會排序的。缺點：有可能遇到ID被刪除的情況，所以需要多選幾個ID。
C．出現sending data的情況：
| 2833185 | sanwenba | 10.241.91.81:45964 | sanwenba | Query | 1 | Sending DATA | SELECT * FROM `www_article` WHERE CONCAT(subject,description) LIKE '%??%' ORDER BY aid DESC LIMIT 75,15
效能sql：
SELECT * FROM `www_article` WHERE CONCAT(subject,description) like ‘%??%’ ORDER BY aid desc LIMIT 75,15
這種sql是典型的sql分頁寫法不規範的情況，需要將sql進行改寫：
SELECT * FROM www_article t1,(SELECT aid FROM www_article WHERE CONCAT(subject,description) LIKE '%??%' ORDER BY aid DESC LIMIT 75,15) t2 WHERE t1.aid=t2.aid;
注意這裡的索引需要改用覆蓋索引：aid+ subject+description
優化後的結果：
總結：
Sql優化是效能優化的最後一步，雖然位於塔頂，他最直影響使用者的使用，但也是最容易優化的步驟，往往效果最直接。
RDS-mysql由於有資源的隔離，不同的例項規格擁有的iops能力不同，比如新1型提供的iops為150個，也就是每秒能夠提供150次的隨機磁碟io操作，所以如果使用者的資料量很大，記憶體很小，由於iops的限制，一條慢sql就很有可能消耗掉所有的io資源，而影響其他的sql查詢，對於資料庫來說就是所有的sql需要執行很長的時間才能返回結果，對於應用來說就會造成整體響應的變慢；所以優化永不止境，既可以幫助你的系統穩定，同時又可以節約你的成本，何樂不為。