EXISTS 比 COUNT(*) 更适合判断存在性，因其找到首条匹配行即终止扫描，避免全量统计；语义精准、支持短路优化、不受NULL影响，且推荐子查询中写 SELECT 1。
EXISTS 为什么比 COUNT(*) 更适合判断存在性
用 COUNT(*) 查“有没有数据”本质是做全量统计，哪怕只找 1 条匹配记录，它也得扫完整个结果集；而 EXISTS 在找到第一条匹配行后立刻返回 TRUE，后续扫描直接中止——这对大表或带复杂 JOIN 的子查询，性能差异可能是几倍甚至几十倍。
常见错误是写成：SELECT COUNT(*) > 0 FROM ... 或嵌套 IF (SELECT COUNT(*) FROM ...) > 0，这不仅多算，还可能因子查询无结果抛出空值警告（尤其在严格 SQL 模式下）。
-
EXISTS只关心逻辑真假，不关心具体行数或内容，语义更精准 - 数据库优化器对
EXISTS子查询有成熟短路优化路径，大多数主流引擎（MySQL 5.7+、PostgreSQL、SQL Server）都支持 - 子查询中用
SELECT 1或SELECT *效果一致，但推荐写SELECT 1，明确表达“只判存在，不要数据”
如何正确写 EXISTS 子查询（含 WHERE 和 JOIN 场景）
核心原则：把待验证的条件放进子查询的 WHERE，主查询只保留 EXISTS 判断逻辑，不要在子查询里加多余字段或聚合。
错误写法：SELECT * FROM orders WHERE EXISTS (SELECT order_id FROM customers WHERE customers.id = orders.customer_id AND status = 'active') —— 这里子查询漏了关联条件，会导致笛卡尔积或误判。
- 单表存在性：
SELECT 1 FROM dual WHERE EXISTS (SELECT 1 FROM users WHERE id = 123) - 跨表关联验证：
SELECT name FROM products WHERE EXISTS (SELECT 1 FROM inventory WHERE inventory.product_id = products.id AND quantity > 0) - 带参数的动态验证（如存储过程中）：
IF EXISTS (SELECT 1 FROM logs WHERE event_type = @type AND created_at > DATE_SUB(NOW(), INTERVAL 1 HOUR)) THEN ...
EXISTS 和 IN / JOIN 在存在性判断中的取舍
很多人下意识用 IN 替代 EXISTS，但二者行为不同：IN 要求子查询结果非空且不能含 NULL，一旦子查询返回 NULL，整条 IN 表达式结果为 UNKNOWN，常被当作 FALSE 导致漏数据；EXISTS 完全不受 NULL 影响。
- 子查询可能返回
NULL值？必须用EXISTS，别碰IN - 子查询结果集很小（NULL，
IN可读性略高，但性能优势微乎其微 - 需要同时获取主表和关联表字段？用
JOIN；仅需判断存在性？EXISTS是更轻量、更安全的选择 - MySQL 中，如果子查询没走索引，
EXISTS和IN都会慢，此时优先检查子查询的WHERE字段是否有对应索引
容易被忽略的 NULL 和相关子查询绑定问题
最隐蔽的坑是：当 EXISTS 子查询里引用了外部列，但该列值为 NULL，整个子查询会恒返回 FALSE（因为 NULL = value 永远不成立），导致“本应存在却判定不存在”。例如：SELECT * FROM orders WHERE EXISTS (SELECT 1 FROM customers WHERE customers.id = orders.customer_id)，若某条 orders.customer_id 是 NULL，这条订单永远进不了结果集。
- 确认业务逻辑是否允许外键字段为
NULL；若允许，且需要包含这些记录，得额外处理：OR orders.customer_id IS NULL - 子查询中避免使用
SELECT *，防止意外引入未索引字段拖慢执行计划 - 在 PostgreSQL 中，
EXISTS子查询可引用上层 CTE，但 MySQL 8.0 之前不支持，注意版本兼容性
真正难的不是写出 EXISTS，而是想清楚“我要验证的存在性，边界在哪”——是严格匹配？是否容忍空值？关联字段有没有索引？这些细节定成败。
