EXISTS 优于 COUNT(*) 判断存在性，因前者命中即停、无聚合开销、语义精准且兼容性强；后者需全量计数、触发聚合计算、受NULL干扰且优化器难推导意图。
EXISTS 找到第一行就停，COUNT(*) 必须数完全部
数据库执行 EXISTS 时，只要子查询命中任意一行匹配数据，立刻返回 TRUE 并终止扫描；而 COUNT(*) 不管你只需要“有没有”，它都得把所有符合条件的行逐个计数——哪怕表里有 500 万行，只第 1 行就满足条件，COUNT(*) 仍会扫完剩下 499.9999 万行。
这种差异在带 JOIN 或多层过滤的子查询中会被放大：索引可能只用上一半，但 COUNT(*) 还是坚持走完执行计划的全路径。
EXISTS 不生成临时结果集，COUNT(*) 会触发聚合计算开销
EXISTS 是纯布尔判断，优化器不保存中间行、不分配聚合内存、不维护计数器状态；COUNT(*) 则必须启动聚合引擎，分配内存空间存储当前计数值，还要处理事务可见性（比如 MVCC 下的版本链遍历），额外消耗不可忽略。
- MySQL InnoDB 中，
COUNT(*)即使走索引，也需遍历索引页并校验每条记录的可见性 - PostgreSQL 对
COUNT(*)的 plan cost 估算通常比等价EXISTS高 3–10 倍 - SQL Server 在执行计划里，
COUNT(*)子查询常出现Compute Scalar+Stream Aggregate节点，而EXISTS多为Left Semi Join或直接索引 Seek
子查询写法不当会让 COUNT(*) 更慢，EXISTS 相对更“耐错”
常见错误写法如 (SELECT COUNT(*) FROM orders WHERE customer_id = c.id) > 0，不仅强制全量统计，还让优化器难以推导语义——它无法确定这个子查询是否真的只用于存在性判断，因此不敢启用短路优化。
而 EXISTS 语法本身即声明意图，主流引擎（MySQL 5.7+、PostgreSQL 10+、SQL Server 2012+）都会主动识别并应用短路路径。
- 子查询中写
SELECT 1或SELECT *对EXISTS性能无影响，推荐统一用SELECT 1表达语义 - 若子查询含
GROUP BY或HAVING，COUNT(*)会进一步拖慢，EXISTS则完全绕过这些阶段 - 在严格模式下（如 MySQL
STRICT_TRANS_TABLES），空子查询的COUNT(*)可能引发警告，EXISTS无此风险
别只看“快”，NULL 和语义安全才是隐性成本
用 IN 或 COUNT(*) > 0 判断存在性时，若子查询结果含 NULL，逻辑可能意外失效：IN (NULL) 整体判为 UNKNOWN，常被当作 FALSE 导致漏数据；COUNT(*) 虽不受 NULL 影响，但它的“数数”动作本身与“是否存在”这个业务意图错位。
EXISTS 完全无视 NULL 值，只认“有没有结果集”，语义精准、行为稳定。这点在跨库迁移或升级数据库小版本时特别关键——有些旧版优化器对 COUNT(*) 短路支持不完整，但 EXISTS 的行为始终一致。
