解决SQL_CALC_FOUND_ROWS数据库慢查询问题的解决方案

in WordPress主题 with 0 comment

解决SQL_CALC_FOUND_ROWS数据库慢查询问题的解决方案

最近搬主题在检查站点的过程中,发现数据库有几个慢查询,对于热衷于WordPress站点优化的我来说肯定不能接受。查看后显示SQL_CALC_FOUND_ROWS查询数据库为慢查询,于是百度了一番,最终进行捣鼓解决了,接下来搬主题就分享一下解决SQL_CALC_FOUND_ROWS数据库慢查询问题的解决方案。

一般我们如果经常查看WordPress日志的话,或者有WordPress站点监测,则有可能看到如下类似慢查询

1、什么是SQL_CALC_FOUND_ROWS,为什么它不好?

SQL_CALC_FOUND_ROWS是一个较早的MySql函数,用于返回一个数据库查询的总行数。你需要知道一个查询返回的总行数,以便计算分页所需的页数。问题是,这是一个相当古老的函数,没有得到很好的优化,而且效率特别低,会拖慢你的数据库查询。在谷歌上简单搜索一下 “SQL_CALC_FOUND_ROWS”,就会发现一页又一页关于速度的抱怨,以及对使用它或使用COUNT()运行二级查询的比较。一般的共识是,运行二级查询通常更快,因为COUNT()不需要麻烦地加载整个表。

不幸的是,在WordPress中有几个地方使用SQL_CALC_FOUND_ROWS,几乎所有的大查询类都使用(WP_Query、WP_User_Query等等),而且它没有显示出很快就会消失的迹象。

2、问题分析

一般在网站数据量小的时候,基本没什么问题,如果当文章数量到10w+的时候,这个就是一条必现的慢查询,有时候上千条的时候也会偶尔出现。比如首页、分类、标签、搜索页面,只要用到这几个函数,就都会使用SQL_CALC_FOUND_ROWS这个方式。

那么,如何解决?

这里搬主题使用的是禁用掉SQL_CALC_FOUND_ROWS用法,用一种更加高效的方式,这里我们用EXPLAIN方式,为什么用EXPLAIN而不是count(*)?

select count(*)是MySQL中用于统计记录行数最常用的方法。count方法可以返回表内精确的行数,每执行一次都会进行一次全表扫描,以避免由于其他连接进行deleteinsert引起结果不精确。

在某些索引下是好事,但是如果表中有主键,count(*)的速度就会很慢,特别在千万记录以上的大表。如果用 explain 命令速度会快很多,因为 explain 用并不真正执行查询,而是查询优化器【估算】的行数

在一个1500万条记录的表中测试,用select count(*)耗时15s,而用explain耗时0.08秒,

两者相差差不多有200倍之多(第一次执行会稍慢,3秒左右)。

如下是explain方式:

注意,这里用的是select *,不是select count(*)

select *会返回一行数据,包括估算行数rows,在PHP中我们fetch(),再通过$result['rows']就可以拿到这个预估值。

select count(*)则会在extra中有一行Select tables optimized away,不会拿到函数估算值。

所以,在对数据准确性要求不高,但是对速度要求很苛刻的场合,绝对有必要用这个估算值代替。

你也可以用下面这句,结果和explain一模一样:

根据实际情况任选一个,都是同一个东西。

3、解决办法

关于解决SQL_CALC_FOUND_ROWS数据库慢查询的方法如下,将以下代码放在自己主题文件夹的functions.php文件内:

购买/下载遇到问题?可联系
闲鱼名称:三点水帅哥
客服邮箱:382813125@qq.com
安装、使用问题,请先查看:技术支持说明

Responses