慢wp_term_relationships查询

Question

我正在运行一个大型WP实例(目前在自定义类型中有28,000+文章)，并且一直在经历一些奇怪的减速。在分析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_video、s5_post、s5_one_liner和s5_image是我们的自定义类型)

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

现在，分析了23,000行是很多的，但并不糟糕，特别是对于一个不经常运行的查询。实际上，在我的手动测试中，大多数情况下，这个查询只需要50‘s左右就能执行(大概是因为它还在MySQL的查询缓存中)。然而，有时，查询需要12-16秒才能执行。

我想我有两个问题：

1. 我们的中期VPS有足够的能力来处理这类查询(8 CPU，4GB RAM)。SQL结果显示，MySQL实际上是使用键生成结果。考虑到我们服务器的容量，以及键的使用，12-16秒来分析24k行是不是有点极端？(大约每秒1500行。(真恶心！)为什么会发生这种情况？这种情况是否发生在其他人的大型WP实例上？
2. 对该怎么做有什么建议吗？通常，在这种情况下，我会添加索引来加快速度，但是MySQL已经使用了正确的键。据我所知，这个查询内置于Wordpress核心(不是我们的自定义代码的一部分)，而且非常简单，以至于我想不出如何进一步优化它.？

Answer 1

为一个不满意的答案做好准备..。

经过几天的测试，我得出的结论是，简单地说，这不是Wordpress的“错误”。我认为服务器上的另一个相关问题是给系统带来了过度的压力。这只是较慢的查询之一，由于服务器处于紧张状态，它很快就上升到我们的慢速查询日志的顶部，时间为12-16秒。

这并不意味着我对23,608 (VERY BAD, VERY SLOW)的连接大小感到满意。但是，这确实意味着对于访问此问题的其他人来说，解决具体问题的方法可能是检查整个系统，以确定为什么这个(或另一个)查询执行得如此糟糕。

编码愉快！