mysql - MySQL LEFT JOIN与2个独立查询(性能)

我有两个表：

++++++++++++++++++++++++++++++++++++
|              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=?

接着
    选择
        ID，
        评论
    从
        游戏评论
    哪里
        GameID =？

显然，查询1在编写代码较少的情况下将是“更简单的”，而在逻辑上，查询1在逻辑上似乎将变得“更容易”，因为它只查询一次Games表。问题是，何时真正降到性能和效率上真的有区别吗？

最佳答案

时间选项1的绝大部分时间就是要走的路。在拥有大量数据之前，无法衡量两者之间的性能差异。把事情简单化。

您的示例也是相当基本的。大规模地，性能问题可以根据要过滤，合并和提取的字段开始显示出来。理想的情况是仅提取索引中存在的数据（尤其是InnoDB）。通常这是不可能的，但是一种策略是在可能的最后时刻提取所需的实际数据。这是选项2的工作方式。

在极端情况下，您根本不需要在数据库中进行任何联接。您的“联接”将发生在代码中，从而最大程度地减少了通过网络发送的数据。选择选项1，直到您开始遇到性能问题，这可能永远不会发生。