【问题标题】:Why does order by primary index make this query slow?为什么按主索引排序会使此查询变慢?
【发布时间】:2011-12-11 01:33:49
【问题描述】:

这个查询正在获取用户订阅上传的最新视频,它的运行速度非常慢,所以我重写了它以使用连接,但它没有任何区别,在修改它之后我发现删除 ORDER BY 会成功运行速度很快(但它违背了查询的目的)。

查询:

SELECT vid. *
FROM video AS vid
INNER JOIN subscriptions AS sub ON vid.uploader = sub.subscription_id
WHERE sub.subscriber_id = '1'
AND vid.privacy = 0 AND vid.blocked <> 1 AND vid.converted = 1
ORDER BY vid.id DESC
LIMIT 8

运行解释,它会在订阅表中显示“使用临时;使用文件排序”,而且速度很慢(0.0900 秒)。

如果没有 ORDER BY vid.id DESC,它不会显示“使用临时;使用文件排序”,因此速度很快(0.0004 秒),但我不明白其他表如何影响它。

所有字段均已编入索引(隐私屏蔽和转换字段对性能的影响不会超过 10%)。

我会粘贴完整的解释信息,但我似乎无法使其适合本网站的布局。

【问题讨论】:

  • 你应该包含索引和执行计划,尝试使用&lt;pre&gt;标签

标签: mysql performance join sql-order-by inner-join


【解决方案1】:

您将查询限制为 8 个结果。当你在没有order by 的情况下运行它时,它可以抓取它遇到的通过条件的前 8 行,然后将它们交还。砰,完成了。

当您使用order by 时,您不需要任何 8 条记录。您要求以vid.id 表示的 8 条记录。所以它必须弄清楚它们是什么,唯一的方法是查看整个表并比较vid.id 的值。这还有很多工作要做。

列上真的有索引吗?如果是这样,它可能已经过时了。您可以尝试重建它。

【讨论】:

  • 有一个索引和它的一个主索引,尝试修复和优化它并没有改变速度。同样使用该表本身,按 id 排序非常快。
【解决方案2】:

通过建议mysql使用带有USE_INDEX(PRIMARY)的主索引来修复它

SELECT vid. *
FROM video AS vid USE INDEX ( PRIMARY )
INNER JOIN subscriptions AS sub ON vid.uploader = sub.subscription_id
WHERE sub.subscriber_id = '1'
AND vid.privacy =0
AND vid.blocked <>1
AND vid.converted =1
ORDER BY vid.id DESC
LIMIT 8

【讨论】:

  • 这很有趣。知道它之前在做什么吗?使用不同的索引?
猜你喜欢
  • 1970-01-01
  • 2021-10-12
  • 1970-01-01
  • 2021-04-04
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多