高流量WordPress新闻站：MySQL昂贵查询生成原因及排查求助

作为常年折腾高流量WordPress新闻站点的开发者，我太懂盯着SHOW PROCESSLIST看到一堆"Sending Data"查询时头大的感觉了。结合新闻站点的特性，下面这些是最常见的元凶，以及定位思路：

1. 不良的插件/主题代码 #

• 未优化的内容聚合查询：很多新闻主题会做热门文章、相关推荐、专题归档这类复杂聚合，如果开发者写WP_Query时没加no_found_rows => true（不需要分页的场景）、没限制posts_per_page，或者用了meta_query/tax_query却没给对应字段加索引，很容易触发全表扫描的慢查询。
• 实时统计类插件：不少流量统计、热门文章插件会在前端请求时实时计算数据，频繁读写wp_postmeta表，高流量下直接把数据库资源占满。
• 缓存插件配置失误：比如缓存插件没排除动态内容的查询，或者缓存过期时间太短，导致大量重复请求直接命中数据库，而非缓存。

2. 数据库索引缺失或不合理 #

WordPress默认索引未必能支撑新闻站点的复杂查询：

• 若经常用自定义字段（比如标记头条、专题）筛选内容，但没给wp_postmeta的meta_key+meta_value组合加索引，会导致每次查询都扫全表。
• 分类/标签查询频繁的话，wp_term_relationships的term_taxonomy_id或object_id索引可能需要优化，否则关联查询会变慢。
• 旧数据堆积：新闻站点日积月累的文章、评论、日志会让表变得异常庞大，没定期清理的话，哪怕有索引，查询效率也会暴跌。

3. WordPress核心与自定义代码问题 #

• 未利用缓存机制：如果主题或自定义代码直接调用get_posts或原生MySQL查询，却没用到WordPress的transient缓存、对象缓存（比如Redis），每一次请求都直接查数据库，高流量下必然崩溃。
• 分页查询滥用：列表页如果设置了过大的posts_per_page，或者分页逻辑没处理好，会频繁触发COUNT(*)这类昂贵的统计查询——尤其是当wp_posts表有几十万条数据时。
• 后台操作冲突：有人在后台批量编辑文章、导入内容，或者运行WP-CLI命令（比如批量生成/修改文章）时，大量写查询会和前端读查询抢占数据库资源，导致前端查询陷入"Sending Data"状态（本质是数据库在处理海量数据，无法及时返回结果）。

4. "Sending Data"状态的深层原因 #

很多人误以为这个状态是数据库在发数据给PHP，其实大部分时候是数据库在处理查询结果的阶段：

• 查询包含ORDER BY但对应字段没加索引，导致数据库需要全表扫描后再排序（也就是EXPLAIN里的Using filesort）。
• 多表关联查询（比如wp_posts关联wp_postmeta、wp_term_relationships）没做好关联条件，产生笛卡尔积或者加载大量临时数据。
• 查询返回的结果集太大，比如一次查几百上千条文章的所有字段，数据库需要打包海量数据返回，耗时极长。

定位查询来源的实用方法 #

既然你找不到生成来源，试试这几个招：

• 开启WordPress的WP_DEBUG_LOG，把数据库查询日志记录下来，日志里会显示每个查询对应的调用栈（哪个文件、哪个函数触发的）。
• 用EXPLAIN分析那些慢查询，看是全表扫描还是索引未命中，再反向查找对应的代码。
• 暂时禁用所有插件，切换到默认主题（比如Twenty Twenty-Four），观察数据库负载是否下降，逐步排查是哪个插件/主题搞的鬼。

内容的提问来源于stack exchange，提问作者Slavic