SQL: 当 WHERE index IN (1,2) ORDER BY Primary 时避免文件排序
SQL: Avoid filesort when WHERE index IN (1,2) ORDER BY Primary
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 不同。所以我不知道为什么会这样。
嗯，我想我已经知道所有的答案了。这就是 blog_id 索引的样子：
(blog_id,post_id)-> (1,55) (1,59) (1,69) (2,57) (2,71)
搜索一个索引id时，不需要做任何文件排序，因为每个blog id中的primary id已经排好了。
在搜索更多 ID ASC 或 DESC 时，它需要进行文件排序，因为主要 ID 在所有索引中的顺序都不正确。
关于力量指数。如果不使用它，数据库将搜索与索引匹配的所有 post id 并对其进行排序，如果有很多，查询可能会很慢。
如果我使用它，Db 将从 PRIMARY 的底部 post_id 到 post_id 然后检查二级索引上的索引键，直到它找到 LIMIT 量如果有 LIMIT，在在这种情况下，它不会获取和排序所有 posts_id，但它必须检查两个索引，如果匹配的 ids 在索引中很远，它也可能很慢。这是一个问题，平均查询是多少。
组合索引 (post_id,blog_id) 和 forced 的选项与 PRIMARY 一样有效，所以我找不到任何其他可能的选项。如果有人可以添加一些关于制作某种性能更好的索引的可能性的提示，我会将您的答案标记为正确。目前还没有答案，这就可以了。
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 不同。所以我不知道为什么会这样。
嗯，我想我已经知道所有的答案了。这就是 blog_id 索引的样子：
(blog_id,post_id)-> (1,55) (1,59) (1,69) (2,57) (2,71)
搜索一个索引id时，不需要做任何文件排序，因为每个blog id中的primary id已经排好了。
在搜索更多 ID ASC 或 DESC 时，它需要进行文件排序，因为主要 ID 在所有索引中的顺序都不正确。
关于力量指数。如果不使用它，数据库将搜索与索引匹配的所有 post id 并对其进行排序，如果有很多，查询可能会很慢。 如果我使用它，Db 将从 PRIMARY 的底部 post_id 到 post_id 然后检查二级索引上的索引键，直到它找到 LIMIT 量如果有 LIMIT，在在这种情况下，它不会获取和排序所有 posts_id，但它必须检查两个索引，如果匹配的 ids 在索引中很远，它也可能很慢。这是一个问题，平均查询是多少。
组合索引 (post_id,blog_id) 和 forced 的选项与 PRIMARY 一样有效，所以我找不到任何其他可能的选项。如果有人可以添加一些关于制作某种性能更好的索引的可能性的提示，我会将您的答案标记为正确。目前还没有答案，这就可以了。