MySQL的左連接對2個單獨的查詢（性能）

Question

我有兩個表：

++++++++++++++++++++++++++++++++++++ 
|    Games    | 
++++++++++++++++++++++++++++++++++++ 
| ID | Name | Description  | 
++++++++++++++++++++++++++++++++++++ 
| 1 | Game 1 | A game description | 
| 2 | Game 2 | And another  | 
| 3 | Game 3 | And another  | 
| .. | ... |  ...   | 
++++++++++++++++++++++++++++++++++++ 

+++++++++++++++++++++++++++++++++++++++ 
|    GameReviews    | 
+++++++++++++++++++++++++++++++++++++++ 
| ID |GameID|   Review   | 
+++++++++++++++++++++++++++++++++++++++ 
| 1 | 1 |Review for game 1  | 
| 2 | 1 |Another review for game 1| 
| 3 | 1 |And another    | 
| .. | ... |   ...    | 
+++++++++++++++++++++++++++++++++++++++ 

選項1：

SELECT 
    Games.ID, 
    Games.Name, 
    Games.Description, 
    GameReviews.ID, 
    GameReviews.Review 
FROM 
    GameReviews 
LEFT JOIN 
    Games 
ON 
    Games.ID = GameReviews.GameID 
WHERE 
    Games.ID=? 

選項2：

SELECT 
    ID, 
    Name, 
    Description 
FROM 
    Games 
WHERE 
    ID=? 

然後 SELECT ID， 評論 FROM GameReviews WHERE GameID =？

很顯然，查詢1會更「簡單」，因爲它只需要編寫更少的代碼，另一個在數據庫上似乎在邏輯上更「容易」，因爲它只查詢Games表一次。問題的關鍵在於什麼時候真的在性能和效率方面存在差異？

Answer 1

絕大多數時間選項1是要走的路。除非你有大量數據，否則兩者之間的性能差異將無法衡量。把事情簡單化。

你的例子也相當基礎。在規模上，性能問題可以基於哪些字段被過濾，加入和拉取而開始顯示。理想的情況是隻提取索引中存在的數據（尤其是InnoDB）。這通常是不可能的，但一種策略是在最後時刻提取您需要的實際數據。這是什麼選項2會做什麼。

在極端規模下，您根本不想在數據庫中進行任何連接。您的「連接」會在代碼中發生，最大限度地減少通過網絡發送的數據。去選擇1，直到你開始有性能問題，這可能永遠不會發生。

Answer 2

轉到選項1，這正是RDBMSes的優化目標。
最好從客戶端打一次數據庫，而不是多次重複打一次數據庫。

我不相信你永遠不會有那麼多的比賽，並回顧了它纔有意義與選項去2.