之前做的一个项目,这段时间看首页访问速度比较慢,想看看那里有问题,需要优化一下,于是查看日志看到这个:
上图很明显,某个程序在循环查询数据库。可能是项目比较着急,所以没有注意优化,先写出来在说。最后随着数据量的越来越大,页面也就越来越卡了。可以看到基本是遍历查询的SQL语句查询时间不长,但是数量众多。
于是博主先查看数据库的数据结构。
表1 gameinfo
表2 gamelabel
很明显,gameinfo表的label字段关联的是labelid的主键ID。单纯的一对一关系可以JOIN来写,
现在是这种不单纯的关系,那么就需要发挥大脑了。
后面博主经过一顿操作猛如虎,写出下面的最终优化语句。即减少了查询时间。也简化了SQL语句。
不废话,直接上代码
SELECT
a.id AS gid,
a.logo AS icon,
a.gamename,
a.duction,
a.gamesize,
from_unixtime(a.gametime, '%m-%d %H:00') AS gametime,
a.downloadcount,
TRIM(
BOTH ','
FROM
LEFT (
GROUP_CONCAT(b.labelname),
10
)
) AS label
FROM
`sy_gameinfo` `a`,
`sy_gamelabel` `b`
WHERE
(
FIND_IN_SET(b.labelid, a.label)
)
AND `state` = 1
GROUP BY
`a`.`id`
ORDER BY
`a`.`downloadcount` DESC
LIMIT 20
博主之所以加上GROUP_CONCAT函数是因为如果不分组的话,会查询许多相同的游戏名称的游戏,所以需要用group分组一下。
执行时间在几万数据的情况下载执行时间在0.23S左右。所以算是比较成功,后台可以根据where添加索引优化。