exists比count()更快，因其找到首行即停止扫描，而count()需遍历全表；用于存在性判断时语义更直接、优化器更友好，且对null安全。
EXISTS子句为什么比SELECT COUNT(*)更快
因为 EXISTS 在找到第一条匹配行后就立即停止扫描，而 COUNT(*) 必须遍历全部结果集。尤其在大表或带复杂JOIN的查询中，性能差距可能达数倍甚至数量级。
常见错误是写成 SELECT COUNT(*) > 0 做布尔判断——这不仅多一次聚合计算，还容易因NULL值或事务隔离级别导致逻辑偏差。
- 只关心“是否存在”，就别查数据量；查存在性，
EXISTS是语义最直接、优化器最友好的选择 -
EXISTS子查询里用SELECT 1或SELECT *效果一样，优化器会忽略 SELECT 列表内容 - 子查询中避免写
SELECT *后加多余字段（如SELECT id, name FROM ...），虽不影响结果，但易误导后续维护者
如何用EXISTS写一个安全的空结果检查
典型场景：执行某个业务逻辑前，先确认某类记录是否存在。例如“如果用户有未读消息，则发通知”。
正确写法是把检查逻辑嵌入 WHERE 或作为独立语句，而非包裹在 IF 中依赖客户端判断：
SELECT 1 FROM dual WHERE EXISTS ( SELECT 1 FROM messages WHERE user_id = 123 AND is_read = 0 );
- 返回一行
1表示存在；无结果集表示为空 —— 这比查出整行数据再判空更轻量 - 子查询必须相关（correlated）：外部查询能引用子查询中的列，否则变成恒真/恒假（如漏写
WHERE messages.user_id = users.id） - 注意 NULL 处理：
EXISTS对 NULL 安全，子查询里字段为 NULL 不影响判断逻辑
EXISTS vs NOT EXISTS 的常见陷阱
误以为 NOT EXISTS 等价于“主表某字段不在子表中”，其实它对主表的 NULL 值行为很特殊：若主表连接字段为 NULL，NOT EXISTS 仍可能返回 TRUE，导致意外包含数据。
- 检查“用户没有订单”的正确写法不是
NOT EXISTS (SELECT 1 FROM orders WHERE orders.user_id = users.id)，而是确保users.id非 NULL，或额外加AND users.id IS NOT NULL -
NOT EXISTS子查询中若含外连接或 OR 条件，可能让优化器放弃半连接（semi-join）优化，退化为嵌套循环 - 某些旧版 MySQL（NOT EXISTS 的索引使用不积极，建议配合
EXPLAIN看type是否为index_subquery或unique_subquery
在存储过程或应用代码里怎么接住EXISTS的结果
不同数据库返回形式不同：PostgreSQL 和 SQL Server 支持直接用 EXISTS 当布尔表达式；MySQL 不支持，需包装成单值查询。
- MySQL 中推荐写成
SELECT EXISTS(SELECT 1 FROM t WHERE ...)—— 它返回1或0，可直接用于IF判断 - 应用层（如 Python + psycopg2）拿到空结果集时，别用
cursor.rowcount == 0判空，应直接检查cursor.fetchall()是否为空列表 - 不要在循环里反复执行
EXISTS查询；如果要批量判断多个 ID，改用LEFT JOIN或临时表 +IN批量查
EXISTS 就变成常量表达式，查的就不是你想要的那个“是否存在”。
