WordPress网站10W+数据，数据库查询优化。

WordPress在查询post列表时，默认会同时把文章数量也查询出来，

使用这种方式的有：get_posts 、query_posts和WP_Query。

get_posts在4.6.1+已经不用SQL_CALC_FOUND_ROWS，但是query_posts和WP_Query还是会用，所以还须优化。

具体语句如下：

这在网站数据量小的时候，不会引起什么问题，

但是当post数量到10w+的时候，这个就是一条必现的慢查询，

首页、分类、标签、搜索页面，只要用到这几个函数，就都会使用SQL_CALC_FOUND_ROWS这个方式。

如何解决？

方法一：

彻底禁用SQL_CALC_FOUND_ROWS

放在functions.php文件即可：

 

方法二：

如果仍然需要查询文章数量，使用更加高效的EXPLAIN方式代替SQL_CALC_FOUND_ROWS

禁用掉SQL_CALC_FOUND_ROWS用法，用一种更加高效的方式，

这里我们用EXPLAIN方式

具体代码如下，放在functions.php文件即可：

 

为什么用EXPLAIN而不是count(*)？

select count(*)是MySQL中用于统计记录行数最常用的方法。

count方法可以返回表内精确的行数，每执行一次都会进行一次全表扫描，

以避免由于其他连接进行delete和insert引起结果不精确。

在某些索引下是好事，但是如果表中有主键，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一模一样：

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