SELECT post_id FROM posts WHERE blog_id IN (15,16) ORDER BY post_id DESC
Post_id是PRIMARY，blog_id是索引，表是innoDB，DB MariaDB。
这会导致filesort，因为索引blog_id用作键。 Blog_id必须是一个索引，当我查询只搜索一个blog_id = 15时，它会更快。如果blog_id不是索引，或者我使用FORCE INDEX（PRIMARY），问题就解决了，查询速度更快。
问题是我认为你不应该在生产应用程序上使用FORCE INDEX，也不应该使用USE INDEX？这将是第一个问题，我可以强制索引，并将其称为已解决？
第二个问题就是为什么它在这里做文件。如果我理解正确，索引有两个键，索引键和主键，索引是由主键排序的？我想不是因为如果是的话，第一个查询应该能够通过索引进行搜索并按主要顺序进行搜索而不使用filesort。但它在搜索一个id时不使用filesort，我不明白为什么它与multiples id不同。所以我不知道为什么会这样。
答案 0 :(得分：0)
嗯，我想我已经知道了所有的答案。这就是blog_id索引的样子：
(blog_id,post_id)-> (1,55) (1,59) (1,69) (2,57) (2,71)
搜索一个索引ID时，不需要执行任何文件排序，因为每个博客ID中的主要ID已经按顺序排列。
当搜索更多的ID ASC或DESC时，它需要执行一个文件排序，因为主ID在所有索引中都不是有序的。
关于FORCE INDEX。如果不使用它，数据库将搜索与索引匹配的所有帖子ID并对其进行排序，如果有很多查询可能会很慢。 如果我使用它，Db将通过post_id从PRIMARY的底部进入post_id，然后检查二级索引上的索引键，直到它找到LIMIT金额，如果有LIMIT，在这种情况下它不会得到和订购所有的posts_id，但它必须检查两个索引，如果匹配的id远远超过索引，它也可能很慢。这是一个普通查询的问题。
组合索引（post_id，blog_id）和强制的选项与PRIMARY一样，所以我找不到任何其他可能的选项。如果有人可以添加一些关于使某些类型的索引表现更好的可能性的提示，我会将你的答案标记为正确。现在因为没有答案，所以会这样做。