查询不存在的列：该TSQL为何可执行？子查询逻辑是什么？

嘿，这俩问题其实都是TSQL的列名作用域解析规则在搞事情，我给你拆解明白：

问题1：选择不存在的列时，为何该TSQL语句能够运行？其执行逻辑是什么？ #

正常情况下，如果你直接写SELECT NonExistentCol FROM TableA，肯定会弹出“无效的列名”错误，但能运行的情况，大概率是你以为“不存在的列”，被TSQL偷偷解析到了其他作用域里的现有列——这是TSQL的核心解析规则：

• 当你在某个查询块（比如子查询、关联查询）里引用列名时，TSQL会先在当前查询块的FROM子句涉及的表中找这个列；
• 如果找不到，它会自动往上一层查询的作用域找，直到找到匹配的列名；
• 只有当所有作用域都找不到时，才会抛出“无效列名”的错误。

举个实际场景的例子：
假设我们有TableA(Id, UserName)和TableB(Id, Age)，你写了这么个查询：

SELECT UserName 
FROM TableA
WHERE EXISTS (
    SELECT UserName 
    FROM TableB 
    WHERE TableA.Id = TableB.Id
)

这里子查询里的UserName在TableB里根本不存在，TSQL就会去外层的TableA里找——刚好TableA有UserName列，所以子查询被偷偷改成了SELECT TableA.UserName FROM TableB，语句自然能运行，但结果可能和你原本的预期完全跑偏。

简单说：能运行的核心是，你以为不存在的列，其实在更外层的查询作用域里找到了匹配的现有列，TSQL直接用那个列来执行了。

问题2：执行语句SELECT * FROM TableA WHERE TableA.ColumnA NOT IN (SELECT DISTINCT ColumnA FROM TableB)时，已知TableA.ColumnA存在、TableB.ColumnA不存在，为何该语句仍能运行？子查询中发生了什么？ #

这个问题本质上是第一个问题的延伸，还是子查询的列名解析在起作用：

当子查询里的ColumnA在TableB中找不到时，TSQL会自动向上到外层查询（也就是TableA的作用域）去查找，所以子查询实际上被解析成了：

SELECT DISTINCT TableA.ColumnA FROM TableB

这时候子查询的逻辑就变成了：遍历TableB的每一行，取出当前外层TableA行的ColumnA值，然后去重（其实就是单个值，因为是当前行的那个值）。

接下来的执行逻辑就很有意思了：

• 如果TableB是空表：子查询返回空结果集，NOT IN空集合的逻辑是所有行都不满足条件（因为NOT IN要求值不在集合里，但空集合没有任何值，没办法判断“不在其中”，所以结果为false），最终查询返回空；
• 如果TableB有数据：子查询返回的是TableA当前行ColumnA的单值，那么TableA.ColumnA NOT IN (这个值)就等价于TableA.ColumnA != TableA.ColumnA，显然是false，所以最终查询也返回空。

总结一下：语句能运行是因为子查询里的ColumnA被解析成了外层TableA的列，没触发“无效列名”错误，但执行结果肯定和你原本的预期不符——你本来想拿TableB的列来过滤，结果变成了用TableA自己的列做无效判断。

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