Question

对网站进行压力测试＆amp;显然，一切都在破碎。

今天的问题：几页上的WSOD。几个小时后，我将一个页面上的问题缩小到此查询（我希望）：它曾经在一秒钟内运行;现在需要＆gt; 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（和相关表连接）的情况下再次运行查询;仍然需要一个临时表和filesort，所以它似乎是一个索引问题。将开始查看缺失索引的所有表。

Answer 1

您定义了哪些指数？

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

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

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

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

这有帮助吗？

Answer 2

如果我错了，请原谅我，但似乎在生成的解释计划中的'extra'栏下，如果对指定的表和使用的密钥使用或不使用索引，则为其指定。 table：address和key jobs.address_id，不使用索引。

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

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

如何使用mysql EXPLAIN查找可能的问题

2 个答案: