Mysql SQL：当索引按主索引的（1,2）顺序排列时，避免文件排序

Post_id是主要的，blog_id是索引，表是innoDB，数据库是MariaDB

这会导致文件排序，因为索引blog_id用作键。 Blog_id必须是一个索引，当我只搜索一个Blog_id=15时，它会更快。如果blog_id不是索引，或者我使用了FORCE索引（PRIMARY），那么问题就解决了，查询速度更快

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

---

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

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

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

关于力量指数。如果不使用它，DB将搜索所有与索引匹配的帖子ID并对其排序，如果有很多，查询可能会很慢。 如果我使用它，Db将从主索引的底部逐个post_id，然后检查辅助索引上的索引键，直到找到限制量（如果有限制），在这种情况下，它不会获取并排序所有post_id，但它必须检查两个索引，如果匹配的id深入索引，它可能也会很慢。这是一个平均查询量的问题

---

组合索引（post_id、blog_id）和强制索引的选项与主索引一样有效，因此我找不到任何其他可能的选项。如果有人能提供一些提示，说明制作某种类型的索引的可能性，我会认为你的答案是正确的。现在，由于没有答案，这就可以了。

请查看重复查询中的答案。

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