EXISTS 找到一行即停，COUNT() 必须遍历全部行；EXISTS 是短路判断，只检查行存在性，不受 NULL 影响，性能更优且语义清晰；COUNT() 即使有索引也无法提前退出，易引发全表扫描。
EXISTS 找到一行就停，COUNT 必须数完所有行
核心区别在执行逻辑：EXISTS 是短路判断，只要子查询返回任意一行（哪怕全是 NULL），就立刻返回 TRUE 并终止扫描；而 COUNT(*) 必须遍历全部匹配结果，统计总数后才能返回数值——哪怕你只关心“有没有”，它也得把百万行全扫一遍。
常见错误现象：SELECT * FROM users WHERE (SELECT COUNT(*) FROM orders WHERE user_id = users.id) > 0 在订单表没索引或数据量大时，可能从毫秒级拖到秒级甚至超时。
- 如果子查询能走索引（比如
orders(user_id)），EXISTS 通常几毫秒内完成 -
COUNT(*)即使有索引，也要回表或扫描索引全量页，无法提前退出 - 在无索引场景下，
COUNT(*)往往触发全表扫描，EXISTS 同样会慢，但至少不会更差
EXISTS 子查询里写 SELECT 1 还是 SELECT *？
完全没区别。现代数据库（MySQL 8.0+、PostgreSQL、SQL Server、Oracle）在解析 EXISTS 时，直接忽略 SELECT 列表内容，只检查能否生成至少一行结果。写 SELECT 1 是约定俗成的可读性习惯，不是性能必需。
容易踩的坑：
- 别写
SELECT COUNT(*)在EXISTS里——COUNT(*)恒返回一行（值为 0 或正整数），导致EXISTS永远为TRUE - 避免加
GROUP BY或DISTINCT，这会强制去重/排序，破坏短路逻辑 - 子查询中引用外部字段（如
WHERE t2.ref_id = t1.id）必须确保字段名拼写正确且作用域可见，否则报错提示常不明确
IN 和 EXISTS 都能判断存在性，为什么优先选 EXISTS？
关键在对 NULL 的鲁棒性：IN 遇到子查询结果含 NULL 时，整个条件变为 UNKNOWN，查不到任何数据；而 EXISTS 完全不受 NULL 影响——它只认“行是否存在”，不比较值。
典型翻车现场：WHERE status IN (SELECT status FROM orders WHERE active = 1)，只要 orders.status 有 NULL，整条查询就失效。
-
NOT IN更危险：子查询任意一行是NULL，结果恒为空 -
NOT EXISTS没这个问题，语义清晰且安全 - MySQL 5.7 及更早版本对
SELECT NULL处理略有差异，统一用SELECT 1可规避
EXISTS 不等于 JOIN，别用错场景
EXISTS 返回布尔值，只解决“有没有关联记录”；JOIN 返回关联后的完整行集，能取字段、聚合、去重。两者不可互换。
容易被忽略的点：
- 一对多关系下，
JOIN会放大主表行数，EXISTS不会——若用来过滤主表，结果行数一致；若用来统计，COUNT(DISTINCT ...)才是正解 - 需要左关联 + 保留空值，必须用
LEFT JOIN，NOT EXISTS只能模拟过滤逻辑，无法带出右表字段 - 子查询里加
ORDER BY或LIMIT在 MySQL 8.0+ 虽允许，但语义已变（可能只取排序后首行），慎用
真正卡住性能的，往往不是语法本身，而是索引缺失或误判了“存在性”和“取值”的边界。写 EXISTS 前先确认：你到底要的是“有没有”，还是“有哪些”。
