P粉7104789902023-09-01 21:08:35
嗯,也許你可以嘗試為你的表添加索引:https://www.drupal.org/docs/7/guidelines-for-sql/the-benefits-of-indexing-large-mysql -tables#:~:text=Creating Indexes&text=The statement to create index,the index must be distinct。 確保按照你查詢的行添加組合索引。
如果這樣做沒有改善你的查詢時間,那麼應該改進查詢。
P粉0200855992023-09-01 14:23:17
注意:
CONCAT-LEAST-GREATEST - 這是為了建構一個「friends_id」?也許你真正想要一個「conversation_id」?目前,兩個用戶永遠不會有多個“conversation”,對嗎?
如果確實需要,為conversation_id建立一個新欄位。 (目前,GROUP BY是低效率的。)下面的程式碼消除了對這樣一個id的需求。
( SELECT lastid FROM ( ( SELECT from_id, MAX(id) AS lastid FROM messages WHERE to_id = ? GROUP BY from_id ) UNION DISTINCT ( SELECT to_id, MAX(id) AS lastid FROM messages WHERE from_id = ? GROUP BY to_id ) ) AS x ) AS conversations
並且擁有這些「covering」和「composite」索引:
INDEX(to_id, from_id, id) INDEX(from_id, to_id, id)
刪除KEY(to_id),KEY(from_id),因為我的新索引可以處理這兩個索引的所有其他任務。
我認為這具有相同的效果,但運行速度更快。
將它們組合起來:
SELECT * FROM ( ( SELECT from_id AS other_id, MAX(id) AS lastid FROM messages WHERE to_id = ? GROUP BY from_id ) UNION ALL ( SELECT to_id AS other_id, MAX(id) AS lastid FROM messages WHERE from_id = ? GROUP BY to_id ) ) AS latest JOIN messages ON messages.id = latest.lastid ORDER BY messages.id DESC
(加上這兩個索引)
更多
我曾經錯誤地認為UNION DISTINCT可以取代對conversation_id的需求。但事實並非如此。我立即看到了一些解決方案: