EXISTS更高效，因其找到首行即终止扫描；COUNT(*)必须遍历全部匹配行才能统计总数，且易触发全表扫描、内存开销大、在严格模式下可能报错。
EXISTS 找到第一行就停，COUNT(*) 必须扫完全部
数据库执行 EXISTS 时，底层是做“半连接探测”：只要子查询返回任意一行（哪怕只有一列、一个常量），立即返回 TRUE，后续扫描彻底中止。而 COUNT(*) 是聚合操作，必须遍历所有匹配行才能得出总数——哪怕你只关心“是不是 > 0”，它也得数完。
常见错误写法：SELECT COUNT(*) > 0 FROM ... 或嵌套 IF (SELECT COUNT(*) FROM ...) > 0，看似语义清晰，实则强制数据库多走一遍全量路径。
- 大表 + 无索引条件时，
COUNT(*)可能触发全表扫描，耗时从几毫秒拉到几秒 -
EXISTS在命中索引后，往往只需访问 B+ 树的少数几个页节点就能确认存在 - 即使子查询含 JOIN，
EXISTS仍可利用驱动表的过滤结果提前终止内层扫描
子查询里该写 SELECT 1 还是 SELECT *
写 SELECT 1 是明确告诉优化器：“我只关心有没有结果，不关心内容”。虽然多数数据库（MySQL、PostgreSQL、SQL Server）对 SELECT * 和 SELECT 1 在 EXISTS 中的处理已基本等价，但显式写 SELECT 1 更稳妥：
- 避免某些旧版本或特定方言（如早期 Oracle）对
SELECT *做冗余列解析 - 语义更干净，排除字段 NULL 性、权限检查等潜在干扰
- 部分 ORM 或中间件在生成 SQL 时，看到
SELECT 1会跳过结果集映射逻辑，减少内存开销
别写 SELECT id 或 SELECT column_name——除非你真需要那个字段参与外层计算，否则纯属画蛇添足。
COUNT(*) > 0 在严格模式下可能报错
当子查询没返回任何行时，SELECT COUNT(*) FROM ... 返回一行一列（值为 0），没问题；但如果你把它嵌在某些上下文中，比如 MySQL 严格 SQL 模式下的 IF 函数参数，或 PostgreSQL 的 WHERE 子句直接用子查询表达式，就可能因空结果集引发警告甚至错误。
- MySQL 8.0+ 严格模式下：
WHERE (SELECT COUNT(*) FROM t WHERE x=1) > 0虽能运行，但若子查询被重写为关联子查询且无匹配，某些优化路径会触发Subquery returns more than 1 row类误报 - PostgreSQL 对标量子查询要求必须返回单行单列，
COUNT(*)满足，但若不小心写成SELECT COUNT(*) FROM ... GROUP BY ...就直接报错 -
EXISTS天然规避这类问题——它只返回布尔值，不依赖结果集结构
EXISTS 在复杂 JOIN 场景下更容易被优化器选中
当子查询涉及多表 JOIN 时，EXISTS 的执行计划通常比 COUNT(*) 更可控。优化器倾向于将 EXISTS 转为 semi-join，并优先使用外表驱动 + 索引查找的策略；而 COUNT(*) 容易诱使优化器选择物化临时表或排序聚合，尤其在未加 LIMIT 的情况下。
- 例如：
WHERE EXISTS (SELECT 1 FROM orders o JOIN order_items oi ON o.id = oi.order_id WHERE o.user_id = u.id AND oi.status = 'pending')，优化器大概率走u → o → oi的嵌套循环 - 同逻辑改用
COUNT(*) > 0，某些版本 MySQL 会先物化整个orders JOIN order_items结果再计数，内存和 IO 开销翻倍 - 注意：如果外表（如
users）非常小，而内表（如orders）极大，EXISTS的 Block Nested Loop 效果才最明显
真正容易被忽略的是：EXISTS 的性能优势不是恒定的——它高度依赖驱动表的选择和索引覆盖程度。没有合适索引时，EXISTS 也会退化成全表扫描，只是比 COUNT(*) 少了一次计数动作而已。
