EXISTS子查询的SELECT列表被数据库引擎完全忽略，仅依赖WHERE条件是否能匹配至少一行；写SELECT 1是为明确表达存在性检查意图，避免误导和非法操作。
EXISTS子查询的SELECT列表被数据库引擎完全忽略
因为EXISTS只关心子查询能否逻辑上生成至少一行，不取任何数据。解析器在语义分析阶段就丢弃了SELECT后的所有列定义，无论写SELECT 1、SELECT *还是SELECT NULL，执行计划里都不会出现列投影操作。
写SELECT 1是为表达意图，不是语法要求
虽然SELECT *和SELECT id也能跑通，但容易误导后续维护者以为你在取数据。用SELECT 1明确传递“只验存在性”的信号：
- 避免误加
ORDER BY或LIMIT（这些在EXISTS子查询里非法） - 防止有人把
SELECT COUNT(*)错塞进去——那会恒返回一行，让EXISTS永远为TRUE - 部分数据库（如PostgreSQL）对
SELECT *在相关子查询中可能多做一次元数据检查，虽不影响结果，但徒增解析开销
真正影响行为的是WHERE条件，不是SELECT内容
EXISTS是否为TRUE，只取决于WHERE（或HAVING）能否匹配出至少一行。以下三者完全等价：
EXISTS (SELECT 1 FROM orders WHERE user_id = u.id) EXISTS (SELECT 'x' FROM orders WHERE user_id = u.id) EXISTS (SELECT NULL FROM orders WHERE user_id = u.id)
但只要WHERE里引用了外部表字段（比如u.id），就必须确保该字段在当前作用域可见——否则报错信息常是“column u.id does not exist”，而不是提示SELECT写法问题。
容易被忽略的边界情况：空集与全NULL行
EXISTS对NULL天然鲁棒：
- 子查询返回一行，哪怕所有列都是
NULL，EXISTS仍为TRUE - 子查询因
WHERE条件全不匹配而无输出，EXISTS为FALSE - 但若子查询本身有语法错误（如表名拼错、字段不存在），整个语句直接报错，不会静默转成
FALSE
这点和IN不同：user_id IN (SELECT nullable_col FROM t)在t含NULL时可能整体判为UNKNOWN，导致查不到数据——而EXISTS没这问题。
