Использование временных, используя filesort плохая идея в mysql?

Question

Я пытаюсь оптимизировать свои mysql-запросы, чтобы избежать использования временных файлов с использованием filesort. Я мог бы помочь. Первый; вот объяснить

Вот на запрос

select pf.*,m.login,m.avatar 
from profile_friends pf, members m 
where pf.friend_id = m.id and pf.member_id = 16586 
order by m.lastLogin desc 
limit 0,24; 


mysql> EXPLAIN select pf.*,m.login,m.avatar from profile_friends pf, members m where pf.friend_id = m.id and pf.member_id = 16586 order by m.lastLogin desc limit 0,24; 
+----+-------------+-------+--------+-----------------------------------------------------+-----------------+---------+--------------------------+------+----------------------------------------------+ 
| id | select_type | table | type | possible_keys          | key    | key_len | ref      | rows | Extra          | 
+----+-------------+-------+--------+-----------------------------------------------------+-----------------+---------+--------------------------+------+----------------------------------------------+ 
| 1 | SIMPLE  | pf | ref | member_id_index,friend_id_index      | member_id_index |  4 | const     | 160 | Using where; Using temporary; Using filesort | 
| 1 | SIMPLE  | m  | eq_ref | PRIMARY,member_id_privacy_index,id_last_login_index | PRIMARY   |  4 | mydb.pf.friend_id  | 1 | Using where         | 

Есть 2 таблицы, связанные. ProfileFriends (pf) и члены (m). Этот запрос просто пытается найти «последних» 24 друзей для этого конкретного идентификатора участника. Последние средства сортируются по дате LastLogin.

Thanks

Answer 1

Это проблема? Да.

Это проблема, когда вы имеете дело с 160 рядами? Неа.

«Filesort» - это метод, а не фактическое создание файла и его сортировка. Если бы мы говорили о 160 000 строк вместо 160 строк, тогда, вероятно, было бы целесообразно рассмотреть дальнейшие оптимизации.

Редактировать: Кроме того, вы исключили фактическое время выполнения запроса. Вы нажимаете индексы и работаете только с несколькими строками. Если этот запрос занимает больше половины доли секунды, это, вероятно, не стоит даже искать для оптимизации.

Answer 2

Это самый эффективный способ написать этот запрос.

Удостоверьтесь, что pf.friend_id, pf.member_id и m.id имеют на них индексы. Затем он будет использовать индексы для объединения таблиц и фильтрации результатов.

Этот вид будет приходить, во всяком случае, из-за вашего order by.

Answer 3

Я думаю, что вы должны быть в состоянии избежать временный/FileSort с индексом на members (id,lastLogin)— в таком порядке — но для этого типа запросов это излишество и судя по вашему EXPLAIN, кажется, вы уже пробовали это?

Вы можете дополнить его PRIMARY/UNIQUE KEY на profile_friends (member_id,friend_id) и посмотреть, как он работает.

В крайнем случае, если запрос выполняется так часто и с таким количеством записей, которые вы должны иметь быстрый ВЫБРАТЬ возможно, вы могли бы денормализовать таблицу и добавить копию members.lastLogin столбца profile_friends с индексом на (member_id,lastLogin). При этом у вас не будет соединения, нет файлов, ничего. С другой стороны, у вас будут большие запросы UPDATE каждый раз, когда кто-нибудь, у кого будет много друзей, снова войдет. Опять же, это кажется совершенно излишним для тех номеров, о которых вы говорите.

Я почти забыл адрес оригинальный вопрос:

Использование временного, используя FileSort плохая идея в MySQL?

Нет, это не так. Если вы можете легко его оптимизировать, вы всегда должны искать «filesort-free» запросы, но в противном случае, если они не представляют реальной проблемы с производительностью, вы не должны беспокоиться об этом. Filesort является частью обычного выполнения запроса.