mysql - 在 mysql 中使用临时文件排序是个坏主意吗？

Question

我正在尝试优化我的 mysql 查询以避免“使用临时文件排序”。我需要一些帮助。第一的;这是解释

这是查询

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) 和 Members (m)。此查询只是试图为该特定成员(member) ID 查找“最近”的 24 个好友。最近意味着按上次登录日期排序。

谢谢

Answer 1

这是一个问题？是的。

当您处理 160 行时，这是一个问题吗？不。

“文件排序”是一种方法，而不是实际创建文件并对其进行排序。如果我们谈论的是 160,000 行而不是 160 行，那么可能有理由考虑进一步优化。

编辑:另外，您省略了实际的查询运行时间。您正在访问索引并且只处理少数几行。如果此查询花费的时间超过几分之一秒，则可能不值得考虑优化。