SQL: Avoid filesort when WHERE index 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 is PRIMARY, and blog_id is index, the table is innoDB, and the DB MariaDB.

This causes filesort because the index blog_id is used as key. Blog_id has to be an index for when I make a query searching for just one blog_id=15, it's faster. If blog_id it's not an index or I use FORCE INDEX (PRIMARY) the problem is solved, and the query is faster.

The thing is that I think you should not use FORCE INDEX on production applications, nor USE INDEX? This would be the first question, can I force the index, and call it solved?

Second question would be why it does filesort here. If I understand correctly, an index has two keys, the index key and the primary key, and the index is ordered by the primary key? I guess not because if it was, that first query should be able to do a search by index and order by primary without filesort. But It does not use filesort when searching for just one id, and I don't see why it's different with multiples ids. So I don't know why it happens.

Answer 1

Well I think I know all the answers already. This is how the blog_id index may look like:

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

When searching for one index id, it does not need to do any filesort because the primary ids within each blog ids are already in order.
When searching for more ids ASC or DESC it would need to do a filesort because the primary ids are not in order in all the index.

Regarding the FORCE INDEX. If not using it the DB will search all post ids that match the index and order them, if there are a lot the query may be slow. If I use it, the Db will go post_id by post_id from the bottom of the PRIMARY and then check the index key on the secondary index, until it finds the LIMIT amount if there is a LIMIT, in this case it would not get and order all posts_id, but it will have to check two indexes, and if the matched ids are far into the index, it may be slow too. It's a matter, of what would be the average query.

The option of a combined index (post_id,blog_id) and forced works just as the PRIMARY, so I don't find any other possible option. If anybody can add some hint about the possibility of making some type of index that will perform better I will mark your answer as correct. For now since there are no answers this will do.