SQL中点符号的使用疑问解析：二叉树节点类型查询案例

问题背景 #

我们有一张存储二叉搜索树（BST）的表，包含两列：

• N：节点的数值
• P：该节点的父节点数值

需求是查询每个节点的类型（Root/根节点、Leaf/叶子节点、Inner/内部节点），并按N升序排序。

现有两个SQL方案：

• 方案1：使用表别名B，通过B.N=P关联，结果正确
• 方案2：未使用表别名的点符号，结果错误

疑问解答 #

1. 方案1正确是否因为点符号？为何P无需点符号？ #

方案1正确的核心是明确指定了关联列所属的表实例，点符号在这里用来区分表别名B对应的列。

当你写B.N=P时，SQL解析器会优先把P识别为当前查询上下文里的主表BST的P列，而B.N是关联查询里别名B对应的表实例的N列，这样就能准确建立“父节点值等于另一个节点数值”的关联关系。

P不用点符号是因为当前查询里没有其他同名的P列，SQL解析器能唯一确定它属于主表的P列；如果查询涉及多个含P列的表，就必须加表别名/表名的点符号来区分，否则会报错或逻辑出错。

2. 把方案2改成BST.N=P仍错误，原因是什么？ #

这是因为直接用原表名自引用会导致列的归属逻辑混乱。

比如你写类似WHERE EXISTS (SELECT 1 FROM BST WHERE BST.N = P)的语句时，BST.N和P都会被解析为子查询里的BST表实例的列，相当于让子查询的表自己和自己对比，完全偏离了“主表节点的父节点值对应另一个节点数值”的逻辑。

而方案1用表别名B，相当于把BST表当成两个独立实例：主查询是一个实例，别名B是另一个实例，这样B.N（子查询实例的节点值）和主查询的P（主实例的父节点值）的关联逻辑才是正确的。如果不用别名直接写BST.N=P，SQL会把两个列都绑定到当前子查询的表实例上，变成判断“当前节点数值等于自己的父节点值”，逻辑完全错误，所以结果不对。

内容的提问来源于stack exchange，提问作者ader