mysql - SQL:当 WHERE 索引 IN (1,2) ORDER BY Primary 时避免文件排序

Question

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

Post_id为PRIMARY，blog_id为index，表为innoDB，DB为MariaDB。

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

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

第二个问题是为什么它在这里进行文件排序。如果我理解正确的话，索引有两个键，索引键和主键，索引是按主键排序的？我想不是，因为如果是的话，第一个查询应该能够按索引进行搜索，并按主顺序进行搜索，而无需进行文件排序。但是当只搜索一个 id 时，它不使用文件排序，而且我不明白为什么它与多个 id 不同。所以我不知道为什么会发生这种情况。

Answer 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 并对它们进行排序，如果有很多，查询可能会很慢。如果我使用它，数据库将从主索引底部逐个post_id，然后检查辅助索引上的索引键，直到找到LIMIT数量(如果有LIMIT)，在这种情况下它将无法获取和排序所有posts_id，但它必须检查两个索引，如果匹配的id离索引很远，它也可能很慢。问题在于平均查询量是多少。

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