4

显然，对网站进行压力测试，一切都在崩溃。

今天的问题：几页上的WSOD。几个小时后，我将一页上的问题缩小到这个查询（我希望）：它曾经在一秒钟内运行；现在它需要> 300。

SELECT   jobs.posting_date                          ,
         jobs.id                                    ,
         jobs.title                                 ,
         addresses.street                           ,
         cities.name                                ,
         states.abbr                                ,
         details.target_url                         ,
         details.description_extracted AS extraction,
         COUNT(jobs_skills.skill_id)   AS skills    ,
         users.first_name
FROM     jobs
         JOIN addresses
         ON       addresses.id = jobs.address_id
         JOIN states
         ON       addresses.state_id = states.id
         JOIN cities
         ON       addresses.city_id = cities.id
         JOIN job_feed_details AS details
         ON       jobs.id = details.job_id
         LEFT JOIN jobs_skills
         ON       jobs.id = jobs_skills.job_id
         LEFT JOIN users
         ON       users.id = details.user_id
WHERE    details.moderated = 0
AND      expiration        = 0
GROUP BY jobs.id
ORDER BY jobs.posting_date DESC

运行EXPLAIN我得到这个：

id  select_type table   type    possible keys           key  key_len    ref                     rows    extra
1   SIMPLE  details ALL job_id                                      537704                              Using where; Using temporary; Using filesort
1   SIMPLE  jobs        eq_ref  PRIMARY,address_id_indexPRIMARY 4   557574_dev.details.job_id       1   Using where
1   SIMPLE  addresses   eq_ref  PRIMARY             PRIMARY     4   557574_dev.jobs.address_id      1   Using where
1   SIMPLE  states      eq_ref  PRIMARY             PRIMARY     1   557574_dev.addresses.state_id   1   Using where
1   SIMPLE  cities      eq_ref  PRIMARY             PRIMARY     4   557574_dev.addresses.city_id    1   
1   SIMPLE  jobs_skills ref     Job_skill           Job_skill   4   557574_dev.jobs.id              4   Using index
1   SIMPLE  users       eq_ref  PRIMARY             PRIMARY     3   557574_dev.details.user_id      1

看看EXPLAIN有没有可能告诉

  • 如果发生任何全表扫描
  • 如果缺少任何相关的切口
  • 哪个表或连接太慢了
  • 我的“寻找慢表”中的任何其他有用信息

更新：在没有 group_by （和相关的表连接）的情况下再次运行查询；仍然需要一个临时表和文件排序，所以它似乎是一个索引问题。将开始查看缺失索引的所有表。

4

2 回答 2

3

你定义了哪些指标？

如果您索引 jobs.address_id、addresses.state_id、addresses.city_id、details.job_id、jobs_skills.job_id、details.user_id 和 jobs.posting_date，您应该能够从索引执行整个连接，而无需触及基础表并运行使用索引排序。

另外，作业是否按posting_date 顺序插入？如果是这样，您可以按 id 而不是按 posting_date 排序，因为它是主键，所以会更快。

解释计划看起来大部分处理都在分组和排序中。你在最后一步有一个文件排序和临时表，这非常昂贵。此外，看起来您在可能应该使用索引的地方使用了 where，因此您可能希望确保所有关联列都已编入索引。

我建议在您的沙箱中加载数据并使用索引组合，直到您的解释计划使用更多索引并且希望没有临时表或文件排序。尽管分组往往很昂贵，但最后一部分可能会有些困难。

这有帮助吗？

于 2011-05-05T17:55:09.280 回答
1

如果我错了，请原谅我，但似乎在生成的解释计划中的“额外”列下，它为您指定了索引是否将用于指定的表和使用的键，例如表：地址和关键作业.address_id，不使用索引。

因此，您需要做的就是记下您在额外列下看到“哪里”的列。对于这样的表，您可以考虑建立索引。

在最大的表上添加索引显然会对性能产生最大的影响，我相信你应该从那里开始。

于 2011-05-05T18:46:47.077 回答