EXISTS 通常比 COUNT(*) 更快，但仅当子查询能走索引并尽早终止扫描时成立；否则可能更慢，需确保关联条件在子查询内、字段有索引，并避免NULL关联失效。
EXISTS 比 SELECT COUNT(*) 快，但只在特定场景下成立
直接用 EXISTS 判断是否存在记录，通常比 SELECT COUNT(*) 更高效——前提是数据库能尽早终止扫描。但这个优势不是自动生效的：如果子查询没走索引、或外层条件写错，EXISTS 反而可能更慢。
- 必须确保子查询中
WHERE条件字段有索引，否则全表扫描照旧 -
EXISTS不关心“有多少条”，只要找到第一条就返回TRUE；而COUNT(*)必须数完所有匹配行 - 别在
EXISTS子查询里写SELECT *，用SELECT 1或SELECT NULL更清晰（语义明确，优化器也更容易识别意图）
写法不对，EXISTS 会变成全表扫描
常见错误是把关联条件写在子查询外部，导致子查询失去过滤能力。比如误写成：
SELECT * FROM users u WHERE EXISTS (SELECT 1 FROM orders o) AND u.status = 'active';
这会让数据库先查一遍整个 orders 表——哪怕你只想看某个用户的订单是否存在。
- 正确写法必须把关联条件放在子查询内部：
EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id) - 如果子查询里漏了
WHERE或用了非索引字段（如o.note LIKE '%abc%'），优化器大概率放弃短路逻辑 - PostgreSQL 和 MySQL 8.0+ 对
EXISTS推导较准；MySQL 5.7 或 SQL Server 2016 以前版本对复杂嵌套支持弱，建议加EXPLAIN确认执行计划
NULL 值和相关子查询的坑
EXISTS 本身不关心值是否为 NULL，但它依赖子查询能否被正确关联。一旦外层字段为 NULL，u.id = o.user_id 整个条件就变成 UNKNOWN，子查询不返回任何行，EXISTS 判定为 FALSE——这常被当成“没数据”，其实是关联失效。
- 检查外层字段是否允许
NULL，比如users.id是主键一般没问题，但users.referer_id就可能为空 - 如果业务上需要包含
NULL关联逻辑，得单独处理：OR u.referer_id IS NULL，不能指望EXISTS自动覆盖 - 避免在子查询里用
LEFT JOIN配合EXISTS，容易让优化器误判驱动表顺序，改用INNER JOIN显式表达意图
什么时候不该用 EXISTS
不是所有“是否存在”都适合 EXISTS。比如你要查“用户有没有未支付订单”，但同时还要取订单金额、时间等字段，硬套 EXISTS 就得额外再查一遍——反而多一次 I/O。
- 纯判断存在性（如权限校验、状态前置检查）：用
EXISTS合理 - 需要后续用到子表数据：改用
LEFT JOIN ... ON ... WHERE ... IS NOT NULL，或者直接JOIN+ 去重 - 表极小（COUNT(*) > 0 更直白
真正卡性能的地方，往往不在语法选哪个，而在子查询能不能命中索引、外层条件是否可下推、以及你有没有看过 EXPLAIN ANALYZE 里的实际行数和循环次数。
