Sql 因此，查询本身的结构不会告诉您首先读取哪个表，或者按照什么顺序计算连接条件

当概念化一个查询时，将一个表的心理图像作为查询的起点可能会有所帮助，但我认为这里的问题答案一定是否定的。从逻辑上讲，没有驱动表。

好的，所以在第二个查询中，您可以轻松地切换TableA和TableC在查询中的位置。所以在这种情况下，根据刚才给出的逻辑，TableC不应该是基表。应该有两个基本表，表A和表C。事实上，如果我们添加更多的表，table，table，它们在TableB中都有列，那么它们都将成为基础表的候选。而且，您的答案甚至有更大的缺陷，因为在我的第一个示例中，我可以将TableB作为第一列并右键连接到TableA，根据您的逻辑，TableB将成为基础表。@big_mike_Boii，如果您希望能够切换TableA和TableC，您可以使用

内部联接。。。更详细地更新了我的答案sallright@big\u mike\u boii我明白你的意思。我对你的问题投了赞成票，让我们看看是否会弹出其他建议！这个答案是荒谬的。如果
加入
是一个
正确的加入
，我会犹豫是否接受任何答案，因为根据我的经验，没有一个
无偏见的数据库爱好者。你给了一个术语一个模糊的伪定义（已经有了技术意义），然后问我们你的意思是什么。那有什么用？你认为“我不认为有”的理由是什么？那有什么用呢？这可以说是离题了，因为所有这些问题都不清楚，过于宽泛和基于观点。你能编辑成一个更具体、更有用的问题吗？您似乎在试图问这样的问题：“在某种意义上驱动查询的表（或多个表？）是否有一个共同的或可以想象的清晰有用的概念”？（有一个合理的具体技术论据支持广义的“否”，所以我回答。）你所说的“基础”是指从“最大”、“驱动”（无论这意味着什么）、“连接自”（无论这意味着什么）和“左边的视觉列”，某个表“显然”是“基础”。相反，根本不清楚“基础”是什么意思。我对你的答案投了赞成票，但我认为你没有提供任何澄清。实际上，我的观点是，正如我的同事所说，基本表充其量只是一个模糊的概念（或者在本例中是“驱动表”）。事实上，正如我相信您知道的，在成熟的关系引擎中进行查询优化非常复杂，正确选择“驱动表”将远远超出so问题的范围。我已经扔掉了多本1000多页的关于查询优化的书，它们都很庞大。
SELECT A.Col1
     , A.Col2
     , A.Col3
     , A.Col4
     , A.Col5
FROM TableA A
 LEFT JOIN TableB B ON B.ID = A.TableBID
 LEFT JOIN TableC C ON C.ID = A.TableCID

SELECT A.*
     , C.*
FROM TableC C
 FULL OUTER JOIN TableB B ON C.ID = B.TableAID
 FULL OUTER JOIN TableA A ON A.ID = B.TableCID

from t1 join t2 using (col)

for each row in t1
    for each row in t2
         compare col
-->  t1 is the "driving table"

for each row in t2
    for each row in t1
        compare col
--> t2 is the "driving table"

for each row in t1
    look up t2 value using index on t2(col)
--> t1 is the "driving table"

sort t1 by col
sort t2 by col
compare the rows in the two sorted sets
--> no "driving table"

hash t1 by col
hash t2 by col
compare the hash maps
--> no "driving table"