Php Joomla3.x中的MySQL查询速度慢得可笑

在我继续之前，让我说，我已经做了谷歌“slow joomla”或“optimize joomla”推荐的所有事情。也就是说，我的站点是gzip的，我所有的css和js都经过优化和缩小，我没有运行任何不必要的组件、插件或模块（事实上几乎没有），我的图像经过优化，缓存打开（页面和渐进式），我在从Rackspace托管的supah fast云上，我的SQL数据库位于单独的Rackspace服务器上

所有这些，我仍然得到10-12秒以上的加载时间，有时多达14-15秒

来自Joomla debug：

Application 0.000 seconds (+0.000); 0.75 MB (+0.755) - afterLoad
Application 0.027 seconds (+0.027); 2.25 MB (+1.491) - afterInitialise
Application 0.040 seconds (+0.013); 3.26 MB (+1.010) - afterRoute
Application 11.986 seconds (+11.947); 5.09 MB (+1.833) - afterDispatch
Application 12.000 seconds (+0.014); 5.63 MB (+0.539) - beforeRenderModule mod_chronoforms (Tip Line)
Application 12.006 seconds (+0.005); 5.85 MB (+0.225) - afterRenderModule mod_chronoforms (Tip Line)
Application 12.008 seconds (+0.002); 5.86 MB (+0.006) - beforeRenderModule mod_custom_advanced (Sponsors)
Application 12.009 seconds (+0.002); 5.88 MB (+0.019) - afterRenderModule mod_custom_advanced (Sponsors)
Application 12.010 seconds (+0.001); 5.87 MB (-0.006) - beforeRenderModule mod_flexi_customcode (Popular Now)
Application 12.012 seconds (+0.002); 5.89 MB (+0.018) - afterRenderModule mod_flexi_customcode (Popular Now)
Application 12.012 seconds (+0.001); 5.84 MB (-0.046) - beforeRenderModule mod_articles_category (Featured Articles)
Application 12.033 seconds (+0.021); 5.97 MB (+0.127) - afterRenderModule mod_articles_category (Featured Articles)
Application 12.033 seconds (+0.000); 5.96 MB (-0.014) - beforeRenderModule mod_search (Search)
Application 12.036 seconds (+0.002); 5.98 MB (+0.022) - afterRenderModule mod_search (Search)
Application 12.036 seconds (+0.001); 5.93 MB (-0.050) - beforeRenderModule mod_acymailing (AcyMailing Module)
Application 12.044 seconds (+0.007); 6.44 MB (+0.507) - afterRenderModule mod_acymailing (AcyMailing Module)
Application 12.157 seconds (+0.114); 6.72 MB (+0.289) - afterRender

afterDispatch的（+11.947）告诉我这可能是MySQL查询的问题，所以我开始通过PHPMyAdmin运行一些长（长，长）查询

我发现这样的查询（第一个为分类博客视图加载了8篇文章——据我所知，第二个执行相同的搜索，减去

限制

，以允许分页）每个都需要2到3秒的时间才能完成，还有40多个奇怪的查询（尽管绝大多数查询远没有那么笨拙）每次加载页面时：

SELECT a.id, a.title, a.alias, a.introtext, a.checked_out, a.checked_out_time, a.catid, a.created, a.created_by, a.created_by_alias, 
  CASE WHEN a.modified = '0000-00-00 00:00:00' THEN a.created ELSE a.modified END as modified, a.modified_by, uam.name as modified_by_name,
  CASE WHEN a.publish_up = '0000-00-00 00:00:00' THEN a.created ELSE a.publish_up END as publish_up,a.publish_down, a.images, a.urls, a.attribs, a.metadata, a.metakey, a.metadesc, a.access, a.hits, a.xreference, a.featured, LENGTH(a.fulltext) AS readmore,
  CASE WHEN badcats.id is not null THEN 0 ELSE a.state END AS state,c.title AS category_title, c.path AS category_route, c.access AS category_access, c.alias AS category_alias,
  CASE WHEN a.created_by_alias > ' ' THEN a.created_by_alias ELSE ua.name END AS author,ua.email AS author_email,contact.id as contactid,parent.title as parent_title, parent.id as parent_id, parent.path as parent_route, parent.alias as parent_alias,ROUND(v.rating_sum / v.rating_count, 0) AS rating, v.rating_count as rating_count,c.published, 
  CASE WHEN badcats.id is null THEN c.published ELSE 0 END AS parents_published 
  FROM mydatabase_content AS a 
  LEFT JOIN mydatabase_content_frontpage AS fp 
  ON fp.content_id = a.id 
  LEFT JOIN mydatabase_categories AS c 
  ON c.id = a.catid 
  LEFT JOIN mydatabase_users AS ua 
  ON ua.id = a.created_by 
  LEFT JOIN mydatabase_users AS uam 
  ON uam.id = a.modified_by 
  LEFT JOIN ( SELECT contact.user_id, MAX(contact.id) AS id, contact.language 
  FROM mydatabase_contact_details AS contact 
  WHERE contact.published = 1 
  GROUP BY contact.user_id, contact.language) AS contact 
  ON contact.user_id = a.created_by 
  LEFT JOIN mydatabase_categories as parent 
  ON parent.id = c.parent_id 
  LEFT JOIN mydatabase_content_rating AS v 
  ON a.id = v.content_id 
  LEFT 
  OUTER JOIN (SELECT cat.id as id 
  FROM mydatabase_categories AS cat JOIN mydatabase_categories AS parent 
  ON cat.lft BETWEEN parent.lft 
  AND parent.rgt 
  WHERE parent.extension = 'com_content' 
  AND parent.published != 1 
  GROUP BY cat.id ) AS badcats 
  ON badcats.id = c.id 
  WHERE a.access IN (1,1,5) 
  AND c.access IN (1,1,5) 
  AND 
  CASE WHEN badcats.id is null THEN a.state ELSE 0 END = 1 
  AND (a.catid = 164 OR a.catid IN ( SELECT sub.id 
  FROM mydatabase_categories as sub 
  INNER JOIN mydatabase_categories as this 
  ON sub.lft > this.lft 
  AND sub.rgt < this.rgt 
  WHERE this.id = 164)) 
  AND (a.publish_up = '0000-00-00 00:00:00' OR a.publish_up <= '2013-08-07 07:00:01') 
  AND (a.publish_down = '0000-00-00 00:00:00' OR a.publish_down >= '2013-08-07 07:00:01') 
  GROUP BY a.id, a.title, a.alias, a.introtext, a.checked_out, a.checked_out_time, a.catid, a.created, a.created_by, a.created_by_alias, a.created, a.modified, a.modified_by, uam.name, a.publish_up, a.attribs, a.metadata, a.metakey, a.metadesc, a.access, a.hits, a.xreference, a.featured, a.fulltext, a.state, a.publish_down, badcats.id, c.title, c.path, c.access, c.alias, uam.id, ua.name, ua.email, contact.id, parent.title, parent.id, parent.path, parent.alias, v.rating_sum, v.rating_count, c.published, c.lft, a.ordering, parent.lft, fp.ordering, c.id, a.images, a.urls 
  ORDER BY 
  CASE WHEN a.publish_up = '0000-00-00 00:00:00' THEN a.created ELSE a.publish_up END DESC , a.created 
LIMIT 0, 7

与

我知道这不会对每个人都有效，因为它可能会破坏分页，但到目前为止，它似乎对我有效（我的模板使用js无限滚动解决方案而不是分页）。我想如果有人在寻找一篇超过一岁的文章，他们可以使用搜索功能

现在，这两个查询的完成时间都不到0.04秒，Joomla Debug的后调度时间减少到1.469秒——这不是最优的，但我可以接受并继续减少这个数字

我知道这个解决方案非常粗糙，可能对其他任何人都不起作用，所以我很想听听关于改进/优化Joomla core和Joomla stock查询的更多想法

非常感谢

---

/编辑2联系人表上的联接和生成的group by存在问题。 这在master中已修复，我认为它应该已经包含在当前版本中。

---

您使用的是Joomla的哪个版本？

我已经在这里发布了：

我取消了对该文件的注释

bind-address="127.0.0.1"

MySQL配置文件（my.ini）中的设置

---

这提高了我在Windows 8.1上本地Joomla安装的执行速度。

我在托管php+mysql的windwos上遇到问题。将主机设置为ip地址

host 127.0.0.1

---

当运行PHPMYADMIN时，查询长度的持续时间是多少？上面列出的第一个查询（设置了

限制0,7

的查询）耗时2.9469秒；第二次用了4.4829秒。我将用

EXPLAIN

s编辑这两个问题。你在哪里找到索引？模式是什么样子的？我知道这有点离题，但根据我的经验，没有“从Rackspace托管supah fast云”这样的东西。我在不同的场合和他们打过两次交道，表现很糟糕。我知道我不是唯一一个有这种问题的人，只是谷歌搜索“rackspace slow”，你会发现，根据很多人的说法，这是他们的一个共同问题。我可能过于热衷于将其称为supah fast——在对我的服务器进行跟踪路由后，我认为你可能是对的。更重要的是，我只是想说明我并不是在说一些GoDaddy共享托管的废话——我是在试图避免回答慢速joomla问题的典型答案（即“不要使用这么多扩展”，“更好地托管”，“投入更多硬件”）。这些都是典型的答案，这让我很恼火，因为它们似乎都是创可贴，覆盖了一个问题的巨大、裂开的胸部伤口。我讨厌在我们应该寻找解决方案的时候治疗症状。

$query->where('(a.publish_up >= DATE_SUB(NOW(), INTERVAL 1 YEAR))');

bind-address="127.0.0.1"

host 127.0.0.1