EXISTS比COUNT()快，因其找到首条匹配行即终止扫描，而COUNT()必须遍历所有满足条件的行才能返回计数值，尤其在千万级表中存在大量无意义计数。
EXISTS比COUNT(*)快在哪？
EXISTS 一找到匹配行就立即返回 TRUE，不扫描全表；而 COUNT(<em>)</em> 必须遍历所有满足条件的行才能返回数字。对千万级表查“是否存在”，用 COUNT() > 0 实际上做了大量无意义计数。
常见错误是写成：SELECT COUNT(*) FROM large_table WHERE ... > 0 —— 这会强制走全索引扫描或全表扫描，哪怕第一条就命中。
正确姿势是让数据库尽早“短路”：只要确认存在一条，立刻停手。
怎么写一个真正高效的EXISTS子查询？
核心是确保子查询能走索引，并且不带无谓的 SELECT * 或聚合。
- 子查询中用
SELECT 1（不是*，也不是具体字段），语义清晰且多数引擎会忽略实际投影 - WHERE 条件字段必须有索引，否则
EXISTS也会退化为全表扫描 - 避免在子查询里写
ORDER BY或LIMIT——EXISTS本身不关心顺序和数量，加了反而可能干扰优化器 - 不要嵌套多层无关子查询，比如
EXISTS (SELECT 1 FROM (SELECT ...) t)，平铺更易优化
示例（高效）：
SELECT EXISTS (SELECT 1 FROM orders WHERE user_id = 12345 AND status = 'paid');
EXISTS在WHERE和SELECT里用法差异
EXISTS 在 WHERE 中是布尔过滤条件，在 SELECT 列表中则返回 TRUE/FALSE（或 1/0，取决于方言）。
- 放在
WHERE：适合做存在性过滤，例如DELETE FROM users WHERE EXISTS (SELECT 1 FROM orders WHERE orders.user_id = users.id) - 放在
SELECT：适合标记“是否有关联记录”，但注意某些数据库（如 MySQL 5.7）返回的是TINYINT，PostgreSQL 返回BOOLEAN
容易踩的坑：
- 在 PostgreSQL 中写
SELECT EXISTS(...)::int才能得到 0/1，直接用可能和应用层类型不匹配 - SQL Server 对
EXISTS子查询中的TOP 1有特殊优化，但加了反而可能让执行计划变差，不建议手动加
为什么有时候EXISTS还是慢？排查要点
即使写了 EXISTS，也可能慢，常见原因：
- 子查询里的字段没索引，尤其是组合条件（如
(user_id, status)没建联合索引，只建了单列索引） - 外层查询驱动了低效的嵌套循环，比如外层是大结果集，每行都触发一次
EXISTS检查（这时应考虑改用LEFT JOIN ... IS NOT NULL或物化中间结果） - 统计信息过期，优化器误判了索引有效性（
ANALYZE table_name或UPDATE STATISTICS可缓解） - 子查询里用了函数或表达式（如
WHERE DATE(created_at) = '2024-01-01'），导致索引失效
千万级表上，别依赖“写了EXISTS就一定快”——先看执行计划里的 Rows Removed by Index Recheck 或 Actual Rows 是否真只查了1行。
