公司有几个网站搭在美国的虚拟主机上,服务器上的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毫秒。
这个页面的事情算了了,先到这里,下次继续。
http://www.bkjia.com/PHPjc/322364.htmlwww.bkjia.comtruehttp://www.bkjia.com/PHPjc/322364.htmlTechArticle公司有几个网站搭在美国的虚拟主机上,服务器上的mysql服务差不多每一天都会突然不知什么时候挂掉,然后过一会又恢复了,怀疑是超出...
Stellungnahme:Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn