Оптимизация запросов, что еще я могу сделать?

Question

Table type: MyISAM 
Rows: 120k 
Data Length: 30MB 
Index Length: 40MB 

my.ini, MySQL 5.6.2 Окна

read_rnd_buffer_size = 512K 
myisam_sort_buffer_size = 16M 

Windows Server 2012, 12GB RAM, SSD 400MB/s

1 медленные запросы:

SELECT article_id, title, author, content, pdate, MATCH(author, title, content) 
AGAINST('Search Keyword') AS score FROM articles ORDER BY score DESC LIMIT 10; 

Исполнительного этот запрос занимает 352ms использует индекс. После профилирования это показывает, что большую часть времени тратится на создание индекса сортировки. (Полная деталь: http://pastebin.com/raw/jT58DCN5)

-Быстрее запросы:

SELECT article_id, title, author, content, pdate, MATCH(author, title, content) 
AGAINST('Search Keyword') AS score FROM articles LIMIT 10; 

Выполнение этого запроса принимает 23МС и делает полное сканирование таблицы, я не хотел полное сканирования таблицы.

Проблема/вопрос: вопрос № 1 - это тот, который мне нужно использовать, поскольку сортировка очень важна.

Есть ли что-нибудь, что я могу сделать для ускорения этого запроса/повторного написания его и достижения того же результата (как №1)?

Цените любой вход и помощь.

Answer 1

Возможно, вы просто слишком много ожидаете? 350 мс для делать

• MATCH(author, title, content) AGAINST('Search Keyword')
• ORDER BY

на 120K записей не звучит слишком потрепанный для меня; особенно если content является «bigish» ...

Имейте в виду, что для вашего «SLOW QUERY» работать, система должна читать каждый строку, вычислить счет, а затем, в конце концов сортировать все оценки, фигура выведите самые низкие 10 значений и затем верните всю соответствующую информацию о строках. Если вы оставите ORDER BY, тогда он просто выбирает первые 10 строк и должен только вычислить score для этих 10 рядов.

Это говорит о том, что я думаю, что EXPLAIN немного вводит в заблуждение, поскольку он, похоже, обвиняет все в СОРТИТЕ, хотя, скорее всего, именно MATCH занимает большую часть времени. Я предполагаю, что оператор MATCH() выполняется «ленивым» способом и, таким образом, запускается только тогда, когда запрашиваются данные, которые в этом случае находятся во время сортировки.

Чтобы понять это, просто добавьте новый столбец score и разделите запрос на 2 части.

• UPDATE articles SET score = MATCH() и др. ...=> Занимает около 300 мс я думаю
• SELECT article_id, title, author, content, pdate, score FROM articles ORDER BY score DESC LIMIT 10; => занимает около 50 мс я предполагаю

Off Конечно, это не рабочий раствор, но если я прав он покажет вам, что ваша проблема а не с помощью SORT, а с полнотекстовым поиском ...

PS: вы забыли упомянуть, что индексы находятся на столе, может быть полезно знать также. ср https://dev.mysql.com/doc/refman/5.7/en/innodb-fulltext-index.html

Answer 2

Попробуйте эти варианты:

AGAINST('word') 
AGAINST('+word') 
AGAINST('+word' IN BOOLEAN MODE) 

Попробуйте

SELECT ... MATCH ..., 
    FROM tbl 
    WHERE MATCH ... -- repeat the test here 
    ... 

Тест устранить те строки, которые не соответствуют вообще, тем самым значительно уменьшая количество строк для сортировки. (Опять же, в зависимости от + и BOOLEAN.)

(I обычно использовать все три:. +, BOOLEAN и WHERE MATCH)

key_buffer_size = 2G может также помочь.

Вам следует подумать о переходе на InnoDB, где FT быстрее.