Каковы правила для заказа ключевых слов в буловом поиске MySQL?

Question

Когда я изменяю порядок ключевых слов в булевом поиске, я получаю тот же результат, но очень разные результаты.

Профилирование на MySQL 5.6.33 с MyISAM таблицы, ft_min_word_len=2 и description_index как FULLTEXT индекс на title и description возвращает это:

# Query 1 
SELECT id 
FROM archive, topic 
WHERE topic.type=0 AND archive.status=2 
AND MATCH(title, description) AGAINST ('+house* +tz*' IN BOOLEAN MODE) 
AND archive.topicId = topic.id 
ORDER BY archive.featured DESC, archive.submissionDate DESC LIMIT 0,20 

Результат:

Total count: 12 
Key_read_requests: 2384607 
Creating sort index: 7.950430 sec (!) 
Duration: 8.851252 sec 

---

# Query 2 
SELECT id 
FROM archive, topic 
WHERE topic.type=0 AND archive.status=2 
AND MATCH(title, description) AGAINST ('+tz* +house*' IN BOOLEAN MODE) 
AND archive.topicId = topic.id 
ORDER BY archive.featured DESC, archive.submissionDate DESC LIMIT 0,20 

Результат:

Total count: 12 
Key_read_requests: 415 
Creating sort index: 0.003449 
Duration: 0.004054 sec 

---

Всего записей в ключевое слово:

tz*: 135092 
tz: 25596 
house*: 12 

Объяснить одинакова для обоих запросов:

id | select_type | Table | Type  | Key    | Key len | Ref    | Rows | Extra 
1 | SIMPLE  | archive | fulltext | description_index | 0  |     | 1 | Using where; Using filesort 
1 | SIMPLE  | topic | eq_ref | PRIMARY   | 3  | archive.topicId | 1 | Using where 

Только Key_read_requests и Creating sort index различаются между 2-запросов.

Кажется, что:

1. порядок порядка ключевых слов является критическим фактором
2. производительности ключевые слова используются в обратном порядке
3. , имеющий самые взыскательные ключевое слово в конце повышает производительность.

Вопросы:

• Что является причиной этой большой разницы в производительности?
• Каковы правила/рекомендации? (Я не мог найти ничего в документации mysql).

Answer 1

Вы запустили оба запроса против нового запущенного экземпляра? Возможно, вы просто набираете обороты плюс из-за заполненных кешей во втором прогоне.

Answer 2

Редактировать после комментария к OP:
Я не уверен в точном плане запроса при разрешении этого запроса.
Иногда одна операция более дорога, чем другая, поэтому при выполнении менее дорогостоящей операции можно сортировать много строк, которые затем не должны проходить через более дорогостоящую операцию, что приводит к сокращению времени работы.
(В вашем примере одна из операций сопоставления может быть дороже, чем другая, которая увеличивает и уменьшает время выполнения, изменяя порядок строк, чтобы они совпадали).