我正在运行一个大的WP实例（目前有28000多个自定义类型的帖子），并且一直在经历一些奇怪的减速。在分析MySQL慢速查询日志时，问题之一是：

SELECT COUNT(*) FROM wp_term_relationships, wp_posts 
WHERE 
    wp_posts.ID = wp_term_relationships.object_id 
    AND post_status = \'publish\' 
    AND post_type IN (\'s5_video\', \'s5_post\', \'s5_one_liner\', \'s5_image\') 
    AND term_taxonomy_id = 1498

（s5\\u视频、s5\\u post、s5\\u one\\u liner和s5\\u image是我们的自定义类型）

对查询进行解释会产生以下结果：

现在，分析的23000行数量很多，但并不可怕，尤其是对于运行频率不太高的查询。事实上，在我的手动测试中，大多数情况下，查询只需要50ms左右的时间即可执行（可能是因为它仍在MySQL的查询缓存中）。然而，有时，查询需要12-16秒才能执行。

我想我有两个问题：

我们的中端VPS有足够的能力来处理这种类型的查询（8个CPU，4GB RAM）。SQL解释结果表明，MySQL实际上是在使用键生成结果。考虑到服务器的容量以及密钥的使用，12-16秒来分析24k行不是有点极端吗？（这大约是每秒1500行。。恶心！）为什么会这样？其他任何大型WP实例上是否发生过这种情况？

有什么建议吗？通常，在这种情况下，我会添加索引以加快速度，但MySQL已经使用了正确的键。据我所知，这个查询内置于Wordpress核心（不是我们自定义代码的一部分），而且非常简单，我想不出如何进一步优化它？