为什么这个查询需要这么长时间？答案

【问题标题】：Why is this query taking so long?为什么这个查询需要这么长时间？
【发布时间】：2011-08-27 07:05:15
【问题描述】：

这个查询出现在我的mysql系统慢日志中，

# Query_time: 37  Lock_time: 0  Rows_sent: 5  Rows_examined: 405199
select euroapps.id, euroapps.name, euroapps.imageurl, euroapps.created,
application_price.retail_price, euroapps.count FROM application_price INNER JOIN
euroapps ON euroapps.id = application_price.application_id WHERE
application_price.storefront_id = '143441' AND application_price.retail_price <= 0
ORDER BY created DESC LIMIT 5;

您看到它检查了 405,199 行，这可能是查询时间长的原因吗？

类似的查询从未出现在我的慢日志中，该查询是：

select euroapps.id, euroapps.name, euroapps.imageurl, euroapps.created,
application_price.retail_price, euroapps.count FROM application_price INNER JOIN
euroapps ON euroapps.id = application_price.application_id WHERE
application_price.storefront_id = '$store' AND application_price.retail_price > 0
ORDER BY created DESC LIMIT 5

这里是解释的输出：

mysql> explain select euroapps.id, euroapps.name, euroapps.imageurl, euroapps.created, application_price.retail_price, euroapps.count FROM application_price INNER JOIN euroapps ON euroapps.id = application_price.application_id WHERE application_price.storefront_id = '143441' AND application_price.retail_price <= 0 ORDER BY created DESC LIMIT 5;
+----+-------------+-------------------+--------+----------------------------------+--------------------------+---------+---------------------------------------------+--------+-----------------------------------------------------------+
| id | select_type | table             | type   | possible_keys                    | key                      | key_len | ref                                         | rows   | Extra                                                     |
+----+-------------+-------------------+--------+----------------------------------+--------------------------+---------+---------------------------------------------+--------+-----------------------------------------------------------+
|  1 | SIMPLE      | application_price | range  | PRIMARY,idx_storedfront_price_id | idx_storedfront_price_id | 9       | NULL                                        | 110491 | Using where; Using index; Using temporary; Using filesort | 
|  1 | SIMPLE      | euroapps          | eq_ref | PRIMARY                          | PRIMARY                  | 4       | itunesapps.application_price.application_id |      1 |                                                           | 
+----+-------------+-------------------+--------+----------------------------------+--------------------------+---------+---------------------------------------------+--------+-----------------------------------------------------------+
2 rows in set (0.00 sec)

【问题讨论】：

如果您还没有它们，我会将索引放在application_price.application_id、application_price.storefront_id 和application_price.retail_price。
@Jason 只是在写同样的东西 :)。另外，application_price.retail_price 列的数据类型是什么？如果该值可以小于零，请确保它是数字并且不是无符号
您可能还想调整 MySQL 的内存设置。我认为，虽然我不确定，“使用临时文件；使用文件排序”意味着 MySQL 正在硬盘上创建某种临时文件以进行排序，而它可能会在 RAM 中进行排序如果内存配置允许它这样做。不要引用我的话，但我最近遇到了类似的问题，增加可用内存解决了这个问题。
另一件可能有帮助的事情：确保所有可能是数字的列是数字的。我在高性能 MySQL 中读到，数字字段的索引比字符串字段更快，因为数字值当然小于字符串值。
我对application_price.application_id、application_price.storefront_id和application_price.retail_price有索引，零售价数据类型为十进制(9,2)

标签： mysql performance explain

【解决方案1】：

您应该查看执行计划，这将有助于缩小原因。 http://dev.mysql.com/doc/refman/5.5/en/execution-plan-information.html

【讨论】：

【解决方案2】：

查看您的 WHERE 子句，您可以看到您使用 application_price.storefront_id 作为过滤因子。但是，在您的 EXPLAIN 中，它不会显示为可能的键，这意味着它没有被索引 - 这意味着需要全表扫描。

另一个因素是application_price.retail_price、you can see what RANGE in explain means - 但是它的基数显然很低 - 因此行数很多。

正如 Jason Swett 建议的那样 - 为您的 application_price.storefront_id 编制索引，您应该会看到更好的性能（Jason 您可能应该发布您的评论作为答案）。

【讨论】：

【解决方案3】：

说明的“行”列表明 MySQL 估计它必须检查 application_price 表中的 110491 行。它也是临时使用的；在这个表上使用文件排序。

如果“created”是 application_price 的一个字段，我建议您为 application_price 添加一个索引，其中包括（storefront_id、application_id、retail_price、created）。这些字段的一些组合应该会有所帮助。

【讨论】：