WordPress 数据量大列表查询慢 SQL_CALC_FOUND_ROWS 惹的祸
随着文章的不断添加，WordPress 变得越来越慢，特别是列表页面严重的卡顿，查看服务器资源占用也都正常，并不是收到攻击或者是程序问题，由于做了缓存，一直认为是偶现的一时查询慢，并没有在意，但是今天发现卡住的时间特别长，刷新了好几次网页都超时，而且其他的网页也打不开，问题还是比较严重的。
发现问题
打开 Navicat 的服务器监控页面，发现在访问列表页面的时候，一个 SQL 执行老是卡住，导致后面的 SQL 执行只能等待：
单独复制出来查看 SQL：
SELECT SQL_CALC_FOUND_ROWS wp_posts.ID FROM wp_posts WHERE 1=1 AND
wp_posts.post_type = 'doc' AND
(wp_posts.post_status = 'publish')
ORDER BY wp_posts.post_date DESC LIMIT 0, 10
刚开始怀疑是没有走索引，所以很慢，随打开 MySQL 查看索引：
执行 EXPLAIN 查看查询的时候是不是用到了索引：
到这里感觉是没有问题，唯一不同的就是使用了 SQL_CALC_FOUND_ROWS 缓存查询结果：
SQL_CALC_FOUND_ROWS 是在 MySQL 4.0 以后加入的，告诉 MySQL 将 sql 所处理的行数记录下来，然后使用 FOUND_ROWS() 则取到了这个纪录，虽然也是两个语句，但是只执行了一次主查询，所以效率比原来要高很多。
于是我把 SQL_CALC_FOUND_ROWS 去掉：
嚯嚯，这执行结果简直天壤之别，找到问题了，就是这个 SQL_CALC_FOUND_ROWS 搞的鬼。
解决方法
知道问题了，那么就来修改下程序，使用 add_filter 修改这个 SQL 语句：
if(is_tax('docs')){ function posts_select_filter ($fields){
return str_replace('SQL_CALC_FOUND_ROWS', '', $fields);
}
add_filter('posts_request', 'posts_select_filter');
}
不对突然想到一个问题，这样修改以后会不会导致接下来的统计条数出错，后续再来解决吧，先把查询慢的问题解决了。
总结
总的来说，对于少量数据，使用 SQL_CALC_FOUND_ROWS 确实是比较高效，但是如果数据量大就还是老老实实的 count(*) 吧！
以上是 WordPress 数据量大列表查询慢 SQL_CALC_FOUND_ROWS 惹的祸 的全部内容， 来源链接： utcz.com/p/233351.html
