SQL：当 WHERE index IN (1,2) ORDER BY Primary 时避免文件排序答案

【问题标题】：SQL: Avoid filesort when WHERE index IN (1,2) ORDER BY PrimarySQL：当 WHERE index IN (1,2) ORDER BY Primary 时避免文件排序
【发布时间】：2017-02-10 15:16:08
【问题描述】：

SELECT post_id FROM posts WHERE blog_id IN (15,16) ORDER BY post_id DESC

post_id是PRIMARY，blog_id是index，table是innoDB，DB是MariaDB。

这会导致文件排序，因为索引 blog_id 被用作键。 Blog_id 必须是一个索引，因为当我只搜索一个 blog_id=15 进行查询时，它会更快。如果 blog_id 不是索引或者我使用 FORCE INDEX (PRIMARY) 问题就解决了，查询也更快了。

问题是我认为你不应该在生产应用程序中使用 FORCE INDEX，也不应该使用 INDEX？这将是第一个问题，我可以强制索引并称之为已解决吗？

第二个问题是为什么它在这里进行文件排序。如果我理解正确的话，一个索引有两个键，索引键和主键，索引是按主键排序的吗？我猜不是因为如果是这样，那么第一个查询应该能够在没有文件排序的情况下按索引进行搜索和按主排序。但是它在只搜索一个 id 时不使用文件排序，我不明白为什么它与多个 id 不同。所以我不知道为什么会这样。

【问题讨论】：

查看重复查询的答案。

标签： mysql sql innodb mariadb

【解决方案1】：

嗯，我想我已经知道所有的答案了。这是 blog_id 索引的样子：

 (blog_id,post_id)-> (1,55) (1,59) (1,69) (2,57) (2,71)

在搜索一个索引 id 时，不需要进行任何文件排序，因为每个博客 id 中的主 id 已经是有序的。
当搜索更多 id ASC 或 DESC 时，它需要进行文件排序，因为主 id 在所有索引中都不是按顺序排列的。

关于力指数。如果不使用它，数据库将搜索与索引匹配的所有帖子 ID 并对其进行排序，如果有很多查询可能会很慢。如果我使用它，数据库将从 PRIMARY 底部的 post_id 到 post_id 然后检查二级索引上的索引键，直到找到 LIMIT 数量（如果有 LIMIT），在这种情况下它不会获取和订购所有的posts_id，但它必须检查两个索引，如果匹配的id在索引中很远，它也可能很慢。这是一个平均查询量的问题。

组合索引 (post_id,blog_id) 和强制的选项就像 PRIMARY 一样，所以我没有找到任何其他可能的选项。如果有人可以添加一些关于制作某种类型的索引的可能性会更好的提示，我会将您的答案标记为正确。现在因为没有答案，所以可以这样做。

【讨论】：