改進具體MySQL查詢要少CPU /磁盤密集型

我有正在一個非常非常長的時間來執行（如15秒），這是隻在一個小測試數據集的查詢。改進具體MySQL查詢要少CPU /磁盤密集型

我在尋找幫助改善這一點：

describe SELECT * from people where uid in (SELECT uid2 from friends where uid1=PHP_UID_VARIABLE) order by rand() limit 1; 
+----+--------------------+---------+------+---------------+------+---------+-------+-------+----------------------------------------------+ 
| id | select_type  | table | type | possible_keys | key | key_len | ref | rows | Extra          | 
+----+--------------------+---------+------+---------------+------+---------+-------+-------+----------------------------------------------+ 
| 1 | PRIMARY   | people | ALL | NULL   | NULL | NULL | NULL | 6726 | Using where; Using temporary; Using filesort | 
| 2 | DEPENDENT SUBQUERY | friends | ref | uid1,uid2  | uid1 | 8  | const | 15501 | Using where         | 
+----+--------------------+---------+------+---------------+------+---------+-------+-------+----------------------------------------------+

我知道它是「壞」 - 它同時使用了加入和蘭德公司的訂單（），它永遠不會成爲特別有效。我不確定爲什麼它沒有在「人員」表上使用索引 - 「uid」是主鍵並被索引。

查詢的目的應該是足夠明顯，但對於後人，我在做什麼是選擇從人民表所在的UID的「好友」列表匹配另一個表1個隨機行。

來源

2011-02-04 Rafiq Maniar

試試這個

SELECT p.* 
FROM friends AS f 
LEFT JOIN people AS p ON f.uid2 = p.uid 
WHERE f.uid1=PHP_UID_VARIABLE 
ORDER BY RAND() 
LIMIT 1

來源

2011-02-04 22:04:31 Damp

非常好，效果很好。現在要弄清楚它是如何工作的更好，所以我寫的比我原來的更有效的查詢:) – 2011-02-04 22:11:05

我從來沒有在生產中使用IN子句。

EXISTS 或 NOT EXISTS

現在，有人說沒關係。有人說這很重要。實驗是確定的真實方法。

下面是MySQL文檔：

http://dev.mysql.com/doc/refman/5.0/en/exists-and-not-exists-subqueries.html

我的建議是要學會（「不假思索」）寫EXISTS和NOT EXISTS子句，並堅持「IN」的條款放牛（減去偶爾快速查看數據）。

但對於生產問題，我會說轉儲「IN」。

來源

2011-02-04 22:16:44 granadaCoder

改進具體MySQL查詢要少CPU /磁盤密集型

回答

相關問題