我们在使用 WP_Query 或者 query_posts 进行日志查询的时候，WordPress 都会产生很多 SQL_CALC_FOUND_ROWS 的 SQL 查询。
一般来说这类 SQL 查询，数据库是不会进行缓存。
WP_Query 和 query_posts 其实提供了 no_found_rows 参数可以阻止进行这类的 SQL 查询，比如：
query_posts('no_found_rows=true&cat=1&numberposts=1');
另外说一下：get_posts 函数自动设置了这个参数为 true
感谢水煮鱼大哥：
http://blog.wpjam.com/m/speed-up-wordpress-wp_query-and-query_posts-functions/
这篇文章虽然短，但抓住了 WordPress 查询性能里很典型的一个坑：很多人只盯着模板和缓存，却忽略了查询本身的统计开销。实操时要注意，no_found_rows 适合不需要分页总数的场景；如果你后面还要做页码、总数展示，就不能一刀切关闭。建议先在列表页、归档页和自定义查询里逐个排查，再看数据库慢查询日志验证效果。
WP_Query 为什么会变慢？
常见原因是它会额外执行 SQL_CALC_FOUND_ROWS 相关查询，用来统计总数和分页信息。这类 SQL 往往不易被数据库缓存，查询量一大就会拖慢页面响应，尤其是列表页和日志页更明显。
no_found_rows 参数怎么用？
在 WP_Query 或 query_posts 的参数里加入 no_found_rows=true 即可，表示不需要总数统计，直接跳过相关 SQL。适合不需要分页总数、只取少量数据的场景，能减少数据库负担。
get_posts 还需要手动优化吗？
一般不需要。get_posts 默认已经把 no_found_rows 设为 true，适合做轻量内容获取。如果你改用 WP_Query 或 query_posts，才需要留意是否显式开启这个参数，避免无谓的统计开销。
发表回复