SQL: Избегайте filesort, когда 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 является PRIMARY, а blog_id - индексом, таблица - innoDB и DB MariaDB.

Это вызывает файловорт, поскольку в качестве ключа используется индекс blog_id. Blog_id должен быть индексом, когда я делаю запрос, ищущий только один blog_id = 15, это быстрее. Если blog_id это не индекс или я использую FORCE INDEX (PRIMARY), проблема решена, и запрос выполняется быстрее.

Дело в том, что я думаю, что вы не должны использовать FORCE INDEX для производственных приложений, а также USE INDEX? Это был бы первый вопрос, могу ли я заставить индекс и назвать его решенным?

Вторым вопросом было бы то, почему он здесь fileort. Если я правильно понимаю, индекс имеет два ключа, индексный ключ и первичный ключ, а индекс упорядочен первичным ключом? Думаю, не потому, что если бы это было так, то первый запрос должен был бы выполнять поиск по индексу и порядку с помощью первичного без filesort. Но он не использует filesort при поиске только одного идентификатора, и я не понимаю, почему он отличается от идентификаторов multiples. Поэтому я не знаю, почему это происходит.

Answer 1

Ну, я думаю, что знаю все ответы уже. Это как индекс blog_id может выглядеть следующим образом:

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

При поиске одного индекса идентификатора, это не нужно делать какие-либо FileSort, поскольку первичные идентификаторы в каждом блоге идентификаторами уже в порядке.
При поиске большего количества идентификаторов ASC или DESC ему нужно будет сделать файловый массив, потому что первичные идентификаторы не в порядке во всем индексе.

Что касается ИНДЕКСА FORCE. Если не использовать его, DB будет искать все идентификаторы сообщений, которые соответствуют индексу и упорядочивают их, если их запрос может быть медленным. Если я использую его, Db пойдет post_id по post_id из нижней части PRIMARY, а затем проверит ключ индекса на вторичном индексе, пока не найдет сумму LIMIT, если есть LIMIT, в этом случае он не получит и закажите все posts_id, но он должен будет проверить два индекса, и если совпадающие идентификаторы находятся далеко от индекса, это может быть слишком медленным. Это вопрос, какой будет средний запрос.

Вариант комбинированного индекса (post_id, blog_id) и принудительные работы так же, как и PRIMARY, поэтому я не могу найти другого возможного варианта. Если кто-нибудь может добавить некоторый намек на возможность сделать какой-то индекс, который будет работать лучше, я буду отмечать ваш ответ как правильный. Пока нет ответов, это будет сделано.