Запрос MySQL быстрее в порядке DESC, чем заказ ASC

Question

Я создал простую базу данных (innodb version 5.7.9) с двумя таблицами, post и post_tag.

Сообщение имеет единственный идентификатор поля (большой int), заданный как первичный ключ (около 120 000 записей). Post_tag имеет 2 поля, post_id (большой int) и tag_id (int), а первичный ключ - [post_id, tag_id].

Следующий запрос выполняется в ~ 1мс:

SELECT 
    SQL_NO_CACHE p.id 
FROM 
    post as p 
STRAIGHT_JOIN 
    post_tag t 
WHERE 
    t.post_id = p.id AND t.tag_id = 25 
ORDER BY 
    p.id DESC 
LIMIT 0, 100 

Но если я изменю ORDER BY для ASC, он работает примерно в 100 раз медленнее! И то, что меня интересует ...

Любая идея, почему?

Первоначально я хотел, чтобы идентификаторы отсортированы по DESC, и я заметил, что он был медленнее, чем ASC. Я читал, что естественная сортировка для индекса - ASC, поэтому я вернул все ID (выполнив ID = SOMETHING BIG - ID), но потом он ничего не изменил, поскольку в ASC теперь он медленнее.

Я загрузил базу данных here в случае, если это полезна.

Большое спасибо заранее всем, кто может помочь.

А вот объясните:

Answer 1

Если есть «другие ограничения», тогда все ставки отключены.

Между тем, глядя на то, что у вас есть ...

STRAIGHT_JOIN, USE INDEX и т.д., являются костылей, когда (а) не имеют индекс «правильный», или (б) оптимизатор может» t выяснить, что нужно делать. То есть, ищите другие решения.

В вашем примере вам будет лучше с равными JOIN и INDEX(tag_id, post_id). Это позволило бы довести до post_tagпервый, так как есть статья WHERE, позволяющая фильтровать там. Оптимизатор, вероятно, увидит, что t.post_id и p.id идентичны, поэтому запустите конец (для DESC) (25, post_id) в индексе и сканируйте.Затем он проверяет, есть ли запись post (это единственное видимое использование для post - снова, если есть «другие ограничения», все ставки отключены).

Итак, вернемся к исходному вопросу. STRAIGHT_JOINвынужден смотреть в post первый. Но где 25-е? По-видимому, вблизи конец от post_tag. Следовательно, ASC потребовалось больше времени, чтобы найти 100 (см. LIMIT), чем если сканирование началось с другого конца!

Предполагая, что это многие-ко-многим таблицы отображения, сделайте следующее:

CREATE TABLE post_tag (
    post_id ..., 
    tag_id ..., 
    PRIMARY KEY(post_id, tag_id), 
    INDEX  (tag_id, post_id) 
) ENGINE=InnoDB; 

Я обсуждаю много причин, в my blog.

Если, как было предложено, вы добавляете (tag_id, post_id DESC), не вводите в заблуждение, думая, что DESC означает что-либо - оно распознается, но игнорируется. Оба детали будут сохранены ASC. Что произойдет, так это то, что Оптимизатор достаточно умен, чтобы начать в конце 25-х и отсканировать назад. Вот «доказательство»:

US имеет INDEX(state, population):

mysql> FLUSH STATUS; 
mysql> SELECT city, population FROM US 
      WHERE state = 'OH' 
      ORDER BY population DESC LIMIT 5; 
+------------+------------+ 
| city  | population | 
+------------+------------+ 
| Columbus |  736836 | 
| Cleveland |  449514 | 
| Toledo  |  306974 | 
| Cincinnati |  306382 | 
| Akron  |  208414 | 
+------------+------------+ 
mysql> SHOW SESSION STATUS LIKE 'Handler%'; 
| Handler_read_key   | 1  | -- get started at end of Ohio 
| Handler_read_prev   | 4  | -- read (5-1) more, scanning backwards 

Единственный случай, когда MySQL отсутствует лодку, игнорируя DESC в INDEX декларации: ORDER BY a ASC, b DESC не может использовать INDEX(a,b).

Answer 2

Предположительно, у вас есть индекс по post(id) (это автоматически создается для первичных ключей, например). MySQL иногда обращает внимание на порядок индекса при использовании индекса для ORDER BY.

Изменяя заказ, вы меняете план запроса таким образом, чтобы сортировка была необходима.

Я хотел бы предложить писать запрос, используя только одну таблицу:

SELECT t.post_id 
FROM post_tag t 
WHERE t.tag_id = 25 
ORDER BY t.post_id DESC 
LIMIT 0, 100; 

JOIN не является необходимым для этого запроса, при условии, что все значения post_id относятся к уважительным сообщений (который кажется очень разумным предположением) ,

Для этого запроса индекс на post_tag(tag_id, post_id desc) является оптимальным, и MySQL может сделать правильную вещь для нисходящей сортировки.