缓慢的 MySQL 查询 (Wordpress)答案

【问题标题】：Slow MySQL Queries (Wordpress)缓慢的 MySQL 查询 (Wordpress)
【发布时间】：2012-01-15 15:26:25
【问题描述】：

由于我的博客导致 mysql 过载，我的虚拟主机暂停了我的帐户。他们让我检查慢查询并通过“索引”它们来解决问题，但我不太明白我应该在这里做什么：

# Query_time: 1.116245  Lock_time: 0.000202 Rows_sent: 10  Rows_examined: 3486
use mydbname
select tag, t.tag_id, count(p2t.post_id) as count, ((count(p2t.post_id)/1070)*100) as weight, ((count(p2t.post_id)/109)*100) as relativeweight
  from wp_tags t inner join wp_post2tag p2t on t.tag_id = p2t.tag_id
  inner join wp_posts p on p2t.post_id = p.ID
  WHERE post_date_gmt < '2011-12-06 09:00:01'
  AND (post_type = 'post')
  group by t.tag
  order by weight desc
  LIMIT 10

# Tue Dec  6 02:00:08 2011
# Query_time: 6.926785  Lock_time: 1.731793 Rows_sent: 10  Rows_examined: 3486
use mydbname
select tag, t.tag_id, count(p2t.post_id) as count, ((count(p2t.post_id)/1070)*100) as weight, ((count(p2t.post_id)/109)*100) as relativeweight
  from wp_tags t inner join wp_post2tag p2t on t.tag_id = p2t.tag_id
  inner join wp_posts p on p2t.post_id = p.ID
  WHERE post_date_gmt < '2011-12-06 09:00:01'
  AND (post_type = 'post')
  group by t.tag
  order by weight desc
  LIMIT 10

我将不胜感激。

谢谢！

【问题讨论】：

标签： mysql performance wordpress indexing

【解决方案1】：

在您做任何其他事情之前，请升级到最新版本的 WordPress，并将您的 UTW 标签结构导入 WordPress 的内置术语架构；如果您在导入之前升级到 WP 3.x，则必须使用像 this one 这样的导入插件。它仍然不是我见过的最有效的 sql，但它比 UTW 标记 sql 更干净，它不是 WordPress 内部的。

我通常同意@Nameless 的第 1 点，但由于您在博客上看到这些查询会导致问题，我想您正在使用 UTW 标记功能，并且您需要从在您可以停用 UTW 之前将 UTW 转换为原生 WordPress 术语，否则您可能会失去您所依赖的功能。

除非您遇到其他与 UTW 无关的 MySQL 问题，否则我不建议您尝试切换到 InnoDB；除非你有一个非常高流量的网站，否则我认为切换表格类型的胜利不值得这样做。

【讨论】：

【解决方案2】：

你真的做不了什么，因为生成这个查询和数据库结构的代码不是你的，重写 wordpress 需要几个月的工作。

但是你可以做一两件事。

问题查询包含 wp_post2tag 表，该表不属于 wordpress 本身，而是属于 Ultimate Tag Warrior 插件。也许删除或禁用此插件会有所帮助。
您可以尝试将wordpress和所有插件升级到最新版本，也许问题已经解决了。
默认情况下，WP 使用不是最优化但随处可用的 MyISAM 表。您可以尝试将数据库迁移到 InnoDB 表。但如果您对 mysql 的工作原理没有深入了解，我不建议您这样做。

【讨论】：

你确定它的 UTW 吗？因为它只是慢查询日志中的几个查询之一：cl.ly/3f3B3d0Q081k1g0i2l1d 谢谢！
@Nimbuz 好吧，从你的其他评论中解释一下，它是罪魁祸首，而且声誉很差。在您的慢日志中，有一些最基本的查询，没有真正的理由执行这么长时间 - 除了被长时间运行的 UTW 查询阻塞了资源。

【解决方案3】：

您需要使用 EXPLAIN 来查看查询计划，它会向您展示可以优化的内容。我怀疑问题出在组和订购部件上。

【讨论】：

您能否有机会将索引添加到数据库中，您能否将其复制到您的服务器上进行使用和优化？

【解决方案4】：

wp_posts:  INDEX(post_type, post_date_gmt)  -- in this order
wp_post2tag:  INDEX(post_id, tag_id)        -- in this order

并删除对wp_tags的所有引用并更改GROUP BY t.tagGROUP BY p2t.tag_id，效果相同，但速度更快。

同时，由于JOINs 发生在COUNT() 完成之前，计算是错误的。所以这个数字可能被严重夸大了。

如果您想要更多讨论，请提供SHOW CREATE TABLE 和EXPLAIN SELECT ...。

【讨论】：