EXISTS比COUNT()>0快，因其找到首条匹配行即终止子查询，而COUNT()必须扫描全部匹配行才能返回计数值，尤其在大表或复杂JOIN场景下性能差距显著。
EXISTS 为什么比 COUNT(*) > 0 快？
因为 EXISTS 在找到第一条匹配行后立刻终止子查询，而 COUNT(*) 必须扫描全部匹配行才能返回数字——哪怕你只关心“有没有”，它也得把整张表或整个 JOIN 结果数完。
这种差异在大表、带 JOIN 或 WHERE 条件过滤性弱的场景下尤为明显。比如查“用户是否有订单”，orders 表有 200 万行，但某用户的第一笔订单在第 3 行就被命中：EXISTS 此时就收手了；COUNT(*) 却仍要扫完所有该用户的订单（可能上千行），再判断是否大于零。
常见错误写法：SELECT COUNT(*) > 0
这类写法不仅多一次聚合计算，还容易引入语义偏差和执行风险：
-
COUNT(*)在子查询无结果时返回0，但嵌套在WHERE中写成(SELECT COUNT(*) FROM t) > 0，某些数据库（如 PostgreSQL 严格模式）可能因子查询为空报错或警告 - 如果子查询含
GROUP BY或HAVING，COUNT(*)会强制完成全部分组计算，而 EXISTS 完全不关心分组逻辑 - 优化器对
COUNT(*) > 0的识别能力弱，很难自动重写为短路逻辑；而EXISTS是明确的存在性语义，各主流数据库（MySQL、PostgreSQL、Oracle）都会优先走索引+短路路径
怎么写才真正快？关键三处不能漏
光把 COUNT(*) > 0 换成 EXISTS 不够，漏掉任一环节都可能白改：
- 子查询里必须写
SELECT 1，不是SELECT *或SELECT id——前者可能触发字段解析开销，后者若字段不存在或类型不匹配，会导致计划退化 - WHERE 条件中必须有外层字段引用，比如
WHERE EXISTS (SELECT 1 FROM orders o WHERE o.customer_id = c.id)；如果漏掉o.customer_id = c.id，就变成恒真判断 - 关联字段（如
customer_id）必须有索引——没索引时，EXISTS 也会逐行全表扫orders，和COUNT(*)一样慢
什么时候换完也没变快？先看执行计划
如果你改完 EXISTS 还是慢，大概率问题不在语法本身：
- 用
EXPLAIN（MySQL）或EXPLAIN ANALYZE（PostgreSQL）确认子查询部分的type是否为DEPENDENT SUBQUERY或index；如果是ALL，说明没走索引 - 检查统计信息是否过期：MySQL 需
ANALYZE TABLE orders，PostgreSQL 需VACUUM ANALYZE orders，否则优化器仍按旧分布估算 - 最常被忽略的一点：瓶颈可能根本不在子查询——
EXPLAIN里真正耗时 90% 的步骤，也许是外层表的全表扫描、网络传输延迟，或是 JOIN 顺序错误
