公司有幾個網站搭在美國的虛擬機器主機上,伺服器上的mysql服務差不多每一天都會突然不知什麼時候掛掉,然後過一會又恢複了,懷疑是超出cpu的使用限制而被自動結束了,但是實際上該伺服器上的流量很小。於是早先的時候聯絡了伺服器供應商的印度阿三客服,想看看是不是其他使用者搞多了害的大家一起死,阿三們尋找了之後,信誓旦旦的拍著長毛的胸部保證不是他們的問題,事情沒有解決。懸著不是個事,只好自己查了,好在可以訪問到information_schema庫,看了看,沒話了,user_statistics裡面的資料顯示我們的一個mysql使用者在busy_time,cpu_time等指標上都高到不行,自己的事,好在阿三沒有發現。於是趕緊查程式,之前的這個網站程式不是由我做的,但是知道裡面問題很多,架構到實現都有問題,但是頁面不是一般的多,代碼夾雜著html,全看過去還不死,(這種時候就尤為的覺著mvc多美妙),平時能湊合著運行就可以了,反正沒有什麼訪問量。
既然是mysql的負擔重,那就先找這個,本地上搞一個網站的鏡像運行下,在my.ini裡修改添加
複製代碼 代碼如下:[mysqld]
log="d:/temp/mysql.log"
log_slow_queries="d:/temp/mysql_slow.log"
long_query_time=1
這個目錄是要已經存在的。重啟mysql服務,就可以記錄了。
查看sql記錄後大吃一驚,查詢的數量驚人,隨便一個頁面,sql查詢都在幾十條,多的有上千條!
以論壇來說吧,一個頁面的資料庫查詢次數也就是10次一下,用了緩衝的還可以再低。這樣算的話,就相當於原來幾十倍的負擔,能不掛?
誰人也不能那邊有毅力寫下上百條的查詢啊,所以肯定是迴圈查詢。sql語句也表明這一點。知道原因了就好改了,找到相關頁面,改掉迴圈查詢,例如,有一個頁面,要顯示所有地區分類和該分類下的文章數,先不考慮資料庫的結構最佳化,就程式而言,原來的大概是這樣子的 複製代碼 代碼如下:$sql1="SELECT aid,count(*) as cc FROM pz_content WHERE uid=$uid group by aid";
$rs1=$db->query($sql1);
if(is_array($rs1)){
foreach($rs1 as $r1){
輸出...
echo id2name($r1->aid);
}
}
............
function id2name($aid)
{
$sql="select ename from pz_area_a where aid_a=".$id;
$result=mysql_query($sql);
$row=mysql_fetch_object($result);
return $row->ename;
}
先不管代碼的容錯,看實現就知道,他先讀取了該使用者的相關文章並按地區ID進行了分組和統計個數,然後再每個地區每個地區地輸出地區名字,所以,如果有1w個地區,這裡就要查詢1w次。放上一個計時的代碼,看了下,大概耗用記憶體6M,執行時間16秒,累計查詢1001次
其實,這裡是只要用一句sql就可以搞定的事情,並不需要迴圈。
複製代碼 代碼如下:$sql1="select pz_area.aid,pz_area.ename,tb1.cc from pz_area right join (SELECT aid,count(*) as cc FROM pz_content WHERE uid=$uid group by aid) as tb1 on pz_area.aid=tb1.aid";
$rs1=$db->query($sql1);
if(is_array($rs1)){
foreach($rs1 as $r1){
輸出...
echo $r1->ename;
}
}
問題就可以解決了。重新運行下,記憶體耗用差不多,查詢1次,CPU執行時間只有647毫秒,和原來的差了26倍!再看一下,發現這個pz_content的表,記錄還算比較多的,有經常要按地區查詢劃分之類的,但是原來什麼索引也沒有。順道在aid上加上一個索引,執行時間縮短到432毫秒。
這個頁面的事情算了了,先到這裡,下次繼續。