使用臨時，使用Filesort在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）。 該查詢正試圖為此特定會員ID查找“最近”的24個朋友。 最近的均值按LastLogin日期排序。

謝謝

Answer 1

有問題嗎？ 是的

處理160行時是否有問題？ 不。

“文件排序”是一種方法，而不是文件的實際創建和排序。 如果我們談論的是160,000行而不是160行，則可能有理由考慮進一步優化。

編輯：此外，您省略了實際的查詢運行時間。 您要命中索引，並且只能處理少量行。 如果此查詢花費的時間不超過一秒的幾分之一，那么即使進行優化也可能不值得。

Answer 2

我認為您應該能夠避免對members (id,lastLogin)進行索引的臨時/文件members (id,lastLogin) 順序 members (id,lastLogin) ，但是對於這種類型的查詢來說，這是過分的，並且通過EXPLAIN判斷，看來您已經嘗試過了？

您可以在profile_friends (member_id,friend_id)上使用PRIMARY / UNIQUE KEY對其進行補充profile_friends (member_id,friend_id)並查看其工作原理。

在最后的手段，如果執行該查詢經常，有這么多的記錄，你必須擁有最快的選擇可能，你可以進行非規范化你的表和你的副本添加members.lastLogin列profile_friends與指數(member_id,lastLogin) 。 這樣一來，您將無需加入，沒有文件排序，什么也沒有。 另一方面，每次有很多朋友的人登錄時，您都會有較大的UPDATE查詢。同樣，對於您所談論的數字來說，這似乎完全過頭了。

我幾乎忘了回答原始問題：

使用臨時，使用Filesort在mysql中是個壞主意？

不，這不對。 如果可以輕松地對其進行優化，則應始終尋求“無文件排序”查詢，否則，除非它們帶來了真正的性能問題，否則您不必擔心。 Filesort是查詢正常執行的一部分。

Answer 3

這是編寫該查詢的最有效方法。

確保pf.friend_id ， pf.member_id和m.id都有索引。 然后它將使用索引來聯接表並過濾結果。

無論如何，由於您的order by這種排序即將到來。