EXISTS子查询是判断结果集是否为空最可靠高效的方式，找到首条匹配记录即返回TRUE；必须搭配完整子查询使用，推荐SELECT 1；NOT EXISTS比COUNT=0更安全，语义明确且对NULL免疫。
EXISTS 子查询是判断结果集是否为空的最可靠方式
直接查 SELECT COUNT(*) 再判断是否为 0，看似直观，但会强制扫描全部匹配行，性能差；而 EXISTS 在找到第一条匹配记录后立即返回 TRUE，不继续遍历，语义清晰且执行高效。
EXISTS 必须搭配子查询使用，不能单独写 WHERE EXISTS(1)
EXISTS 后面必须跟一个完整的子查询（哪怕只 SELECT 1），数据库会忽略子查询中的具体字段，只关心是否存在行。常见错误包括：
- 写成
WHERE EXISTS (SELECT * FROM t WHERE ...)—— 虽然能运行，但*易误导，建议统一用SELECT 1 - 漏写子查询的
FROM或条件，导致语法错误或逻辑错误 - 在子查询中误引用外层表字段却未加别名，引发列歧义
正确写法示例：
SELECT name FROM users u WHERE EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id AND o.status = 'paid')
NOT EXISTS 比 COUNT = 0 更安全，尤其在 NULL 和关联场景下
用 COUNT(*) = 0 判断“不存在”时，若子查询本身因 JOIN 条件不满足而返回空集，容易和 NULL、聚合空结果混淆；NOT EXISTS 语义明确，且对 NULL 完全免疫。
- 适用于“查找没有下单的用户”这类反向需求
- 子查询中若涉及外键字段为
NULL，NOT EXISTS仍能正确返回TRUE；而LEFT JOIN ... IS NULL写法需额外注意连接字段是否可空 - MySQL 8.0+ 和 PostgreSQL 对
NOT EXISTS有较好优化，一般不会比等价的LEFT JOIN慢
EXISTS 不返回数据，只返回布尔值，别指望它带出子查询字段
EXISTS 是谓词（predicate），不是表达式，不能出现在 SELECT 列表里，也不能被赋值给变量（如 SQL Server 的 @var = (SELECT ...) 会报错）。它的作用域仅限于 WHERE 或 HAVING 中的逻辑判断。
- 想同时获取存在性判断 + 关联数据？得用
LEFT JOIN配合CASE WHEN EXISTS(...)子查询（部分数据库支持）或拆成两步 - 在存储过程中需要布尔结果做分支，MySQL 可用
IF EXISTS(SELECT 1 ...)，但 PostgreSQL 必须用PERFORM+ 异常捕获或临时表 - 某些 ORM（如 SQLAlchemy）生成的 EXISTS 查询可能默认包裹
SELECT 1，但若手动拼 SQL，别画蛇添足加AS别名
最容易被忽略的是：EXISTS 的性能优势高度依赖子查询中是否有可用索引——如果 WHERE 条件字段没索引，它照样要全表扫。
