EXISTS 子查询比 COUNT(1) 更快，适用于“是否存在”的布尔判断；它找到首条匹配行即返回 TRUE，而 COUNT(1) 必须遍历全部匹配行，且优化器几乎从不将 COUNT(1) > 0 重写为 EXISTS。
EXISTS 子查询比 COUNT(1) 更快，但只适用于“是否存在”这类布尔判断
当你真正只需要知道“某分组下有没有记录”，而不是“有多少条”，EXISTS 几乎总是更优。它能在找到第一条匹配行后立即返回 TRUE，不扫描全表；而 COUNT(1) 必须遍历所有匹配行才能返回数字结果。
常见错误是写成：SELECT group_id, COUNT(1) > 0 AS has_data FROM t GROUP BY group_id —— 这看似等价于 EXISTS，实则强制执行了完整计数，白白浪费 I/O 和 CPU。
- 适用场景：权限校验（“用户是否有该角色”）、状态前置检查（“订单是否含退货项”）
- 注意：
EXISTS不受GROUP BY直接驱动，需配合相关子查询或LATERAL（PostgreSQL）/APPLY（SQL Server）实现分组级存在性判断 - MySQL 8.0+、PostgreSQL、SQL Server 支持
LATERAL或等效语法，可让子查询按外层分组逐次执行
用 LEFT JOIN + IS NOT NULL 替代 COUNT(1) > 0 实现分组存在性标记
如果数据库不支持 LATERAL，又不想写多层嵌套，一个稳定且高效的做法是：对目标子集先去重聚合，再用 LEFT JOIN 关联回主分组表，最后用 IS NOT NULL 判断存在性。
例如统计每个部门是否有带绩效的员工：
SELECT d.dept_id, CASE WHEN e.dept_id IS NOT NULL THEN 1 ELSE 0 END AS has_perf FROM departments d LEFT JOIN (SELECT DISTINCT dept_id FROM employees WHERE perf_score > 90) e ON d.dept_id = e.dept_id;
-
DISTINCT在子查询中提前去重，避免重复匹配，比COUNT后过滤更轻量 - 相比
EXISTS，此写法更易读、兼容性更好（所有主流 SQL 引擎都支持） - 注意别在子查询里漏掉
WHERE条件——否则DISTINCT dept_id就退化成全表扫描
COUNT(1) 在分组统计中无法被优化掉，即使你只用它做真假判断
优化器几乎从不把 COUNT(1) > 0 重写为 EXISTS，哪怕语义等价。这是因为聚合函数改变了查询语义层级，优化器无法安全地做等价替换。
典型低效写法：
SELECT user_id, COUNT(1) > 0 AS has_order FROM users u LEFT JOIN orders o ON u.user_id = o.user_id AND o.status = 'paid' GROUP BY u.user_id;这会让引擎对每个
user_id 都完整扫描其全部订单（哪怕第一个就满足 status = 'paid'）。
- MySQL 5.7 及更早版本对此类写法几乎无优化能力
- PostgreSQL 12+ 对
NOT EXISTS有较好下推优化，但对COUNT() > 0仍不转化 - 如果必须用
COUNT（比如后续还要复用计数值），请确保加好复合索引，如(user_id, status)
EXISTS 的相关子查询写法容易误写成非关联形式
写 EXISTS 最常见的坑，是忘了在子查询里关联外层表字段，导致变成“只要全表存在一条记录就全为 TRUE”。
错误示例：
SELECT dept_id,
EXISTS (SELECT 1 FROM employees WHERE perf_score > 90) AS has_perf
FROM departments; 这会返回所有部门的 has_perf 都是 TRUE（只要员工表里任意一人达标）。
正确写法必须显式关联：
SELECT dept_id,
EXISTS (SELECT 1 FROM employees e WHERE e.dept_id = d.dept_id AND e.perf_score > 90) AS has_perf
FROM departments d;
- 别依赖列名自动解析——不同方言对未限定列的处理不一致（如 SQL Server 会报错，MySQL 可能静默出错）
- 子查询中尽量只 SELECT
1或NULL，避免SELECT *带来额外列解析开销 - 某些旧版 SQLite 不支持相关子查询中的
GROUP BY或窗口函数，需降级为临时表
EXISTS 还是 COUNT，而不是看哪个写起来顺手。 
