2

此查询出现在我在 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)
4

3 回答 3

1

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

于 2011-05-17T14:21:42.103 回答
1

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

另一个因素是application_price.retail_price，你可以看到解释中的 RANGE 是什么意思——但是它的基数显然很低——因此有这么多行。

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

于 2011-05-17T14:30:35.780 回答
0

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

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

于 2011-05-17T14:30:42.727 回答