|
既然是mysql的負擔重,那就先找這個,本地上搞一個網(wǎng)站的鏡像運行下,在my.ini里修改添加
復制代碼 代碼如下:
[mysqld]
log="d:/temp/mysql.log"
log_slow_queries="d:/temp/mysql_slow.log"
long_query_time=1
這個目錄是要已經(jīng)存在的。重啟mysql服務,就可以記錄了。
查看sql記錄后大吃一驚,查詢的數(shù)量驚人,隨便一個頁面,sql查詢都在幾十條,多的有上千條!
以論壇來說吧,一個頁面的數(shù)據(jù)庫查詢次數(shù)也就是10次一下,用了緩存的還可以再低。這樣算的話,就相當于原來幾十倍的負擔,能不掛?
誰人也不能那邊有毅力寫下上百條的查詢啊,所以肯定是循環(huán)查詢。sql語句也表明這一點。知道原因了就好改了,找到相關(guān)頁面,改掉循環(huán)查詢,例如,有一個頁面,要顯示所有地區(qū)分類和該分類下的文章數(shù),先不考慮數(shù)據(jù)庫的結(jié)構(gòu)優(yōu)化,就程序而言,原來的大概是這樣子的
復制代碼 代碼如下:
$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;
}
先不管代碼的容錯,看實現(xiàn)就知道,他先讀取了該用戶的相關(guān)文章并按地區(qū)ID進行了分組和統(tǒng)計個數(shù),然后再每個地區(qū)每個地區(qū)地輸出地區(qū)名字,所以,如果有1w個地區(qū),這里就要查詢1w次。放上一個計時的代碼,看了下,大概耗用內(nèi)存6M,執(zhí)行時間16秒,累計查詢1001次
其實,這里是只要用一句sql就可以搞定的事情,并不需要循環(huán)。
復制代碼 代碼如下:
$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;
}
}
問題就可以解決了。重新運行下,內(nèi)存耗用差不多,查詢1次,CPU執(zhí)行時間只有647毫秒,和原來的差了26倍!再看一下,發(fā)現(xiàn)這個pz_content的表,記錄還算比較多的,有經(jīng)常要按地區(qū)查詢劃分之類的,但是原來什么索引也沒有。順道在aid上加上一個索引,執(zhí)行時間縮短到432毫秒。
這個頁面的事情算了了,先到這里,下次繼續(xù)。
php技術(shù):php垃圾代碼優(yōu)化操作代碼,轉(zhuǎn)載需保留來源!
鄭重聲明:本文版權(quán)歸原作者所有,轉(zhuǎn)載文章僅為傳播更多信息之目的,如作者信息標記有誤,請第一時間聯(lián)系我們修改或刪除,多謝。