Question

我有一个非常繁忙的wordpress网站。每月> 3M的浏览量。最近几周，我们遇到了MySQL问题。 CPU超过500％（8核，256GB RAM，专用硬件）且性能非常慢。

所以我发现了这个查询数十次。

SELECT wp_posts.ID FROM wp_posts
 INNER JOIN wp_postmeta ON ( wp_posts.ID = wp_postmeta.post_id )
 WHERE 1=1
 AND (wp_postmeta.meta_key = 'tie_views')
 AND wp_posts.post_type = 'post'
 AND ((wp_posts.post_status = 'publish'))
 GROUP BY wp_posts.ID
 ORDER BY wp_postmeta.meta_value+0
 DESC LIMIT 0, 20

似乎正在等待超时然后被杀死。有人可以解释这到底是什么吗？谁能告诉我此查询出了什么问题？

请咨询...

Answer 1

此查询天生没有错。我对其进行了修改，以与现有的数据库配合使用，并且能够在10,000秒内抓取0.0409条记录（在具有21k posts条记录和137k postmeta条记录的数据库中）。就是说，我还对数据库进行了一些修改，包括postmeta表上的部分索引，这确实加快了此类查询的速度。

您会在整个WordPress上注意到的一件事是，越来越大的网站变得越来越慢，尤其是在使用meta_query时。（通常，当您在同一表上与JOIN一起使用多个OR […] WHERE时，情况会更糟，而且更引人注意。）

关于“加快WordPress中的慢速元查询的速度”，有上百万篇文章/ SO问题/文档，但是不幸的是，您会自己找到适合自己的一个。

如果该查询正在运行数十次（每次加载页面？），请确保您正在缓存结果。确保您的Object Caching运行良好，并且还考虑页面缓存-如果还没有的话。

您还可以考虑使用WordPress Transients缓存该查询的结果-基本上将查询结果设置为wp_options表中的一个临时选项，持续了您确定的时间（30秒， 4小时6周，无论如何）-它会从那里拉出，而不是每次都运行查询，直到过期。

最后一件事可能相关，也可能不相关，请确保您的wp_options表没有。肿。许多插件会在其中留下大量肿的信息，以致死亡。并且默认的存储选项将它们设置为autoload: true，这意味着它们会在每页加载时加载到内存中。我见过“轻型/小型/等”网站，其中的wp_options表格过大，其中包含数百兆年的旧垃圾，导致极端的加载时间，超时和崩溃。

所以基本上

寻找加速元查询的方法，因为它们本来就很慢
打开对象缓存和/或使用WP Transients
考虑页面缓存
从选项表中清除无用的垃圾

Answer 2

WP的基本设计是“ EAV”（实体-属性-值）。这是存储活动数据点（例如视图计数器或“赞”计数器）的效率极低的方法。而且，正如您所发现的，它的伸缩性不好。

此类计数器应位于具有数字数据类型的 dedicated 列中。我不知道WP中是否有添加这种列的方法。假设不可能，以下内容将通过改进postmeta的索引来帮助 some ：http://mysql.rjweb.org/doc.php/index_cookbook_mysql#speeding_up_wp_postmeta

此WordPress MySQL DB查询有什么问题？

2 个答案: