直接结论：所有仅判断“是否存在”的COUNT(*)或COUNT(1)子查询都应替换为EXISTS，因其找到首行即终止扫描，避免全量计数；必须显式关联外层变量，且MySQL需包装为SELECT 1 FROM dual WHERE EXISTS(...)。
存储过程里用IF EXISTS代替IF (SELECT COUNT) > 0
直接结论：在SQL Server、PostgreSQL或MySQL（需包装）的存储过程中，所有仅用于判断“是否存在”的COUNT(*)或COUNT(1)子查询，都该换成EXISTS。这不是风格问题，是执行计划层面的硬性优化。
常见错误写法：IF (SELECT COUNT(1) FROM orders WHERE user_id = @uid AND status = 'pending') > 0——这会让优化器强制走索引扫描（Scan），哪怕只有一条待处理订单，也要数完全部匹配行。
- 正确写法是：
IF EXISTS (SELECT 1 FROM orders WHERE user_id = @uid AND status = 'pending') -
SELECT 1比SELECT *更安全：避免旧版MySQL误读宽字段，也防止后续维护者误加业务字段 - MySQL不支持
IF EXISTS直接语法，得包装成单行查询：IF (SELECT COUNT(*) FROM (SELECT 1 FROM orders WHERE ...) AS t) > 0→ 改为IF (SELECT 1 FROM dual WHERE EXISTS (SELECT 1 FROM orders WHERE ...)) IS NOT NULL
EXISTS子查询必须带关联条件，否则逻辑全错
在存储过程里拼接动态条件时，最容易漏掉外层变量引用。比如想查“当前用户有没有激活设备”，却写成：IF EXISTS (SELECT 1 FROM devices WHERE status = 'active')——只要库中任意一个设备激活，所有用户的判断都返回TRUE。
真正有效的写法必须显式关联：IF EXISTS (SELECT 1 FROM devices WHERE user_id = @uid AND status = 'active')。
- 检查点：子查询
WHERE里至少出现一次外层变量（如@uid、@order_id） - 若用
JOIN替代，注意LEFT JOIN ... WHERE right.id IS NULL等价于NOT EXISTS，但语义更绕，易出错 - Oracle和SQL Server对无关联
EXISTS会当成常量表达式（恒真/恒假），而MySQL可能报语法警告
NULL值不会干扰EXISTS，但NOT EXISTS要额外防坑
当判断“用户没下过订单”时，NOT EXISTS (SELECT 1 FROM orders WHERE orders.user_id = @uid)看似合理，但如果orders.user_id允许NULL，那些user_id IS NULL的订单永远不会匹配@uid，导致NOT EXISTS误判为TRUE，把不该包含的用户也拉进来。
安全做法是在子查询中显式过滤NULL：NOT EXISTS (SELECT 1 FROM orders WHERE orders.user_id = @uid AND orders.user_id IS NOT NULL)。
- 更彻底的方案：建表时把外键字段设为
NOT NULL，从源头杜绝该问题 -
EXISTS本身对NULL免疫——子查询里字段为NULL不影响“是否返回行”的判断 - 别依赖
IN做存在性否定，@uid NOT IN (SELECT user_id FROM orders)遇到NULL直接整体失效
为什么改了EXISTS还是慢？先看执行计划再调
换掉COUNT只是第一步。如果性能没变化，大概率是底层支撑没跟上：关联字段没索引、统计信息过期、或者瓶颈根本不在子查询本身。
- 必须跑
EXPLAIN（MySQL）或EXPLAIN ANALYZE（PostgreSQL）：盯住子查询部分的type是否为index_subquery或unique_subquery，而不是ALL - 检查
rows预估数：如果预估扫10万行，实际只返回2行，说明统计信息不准，需执行ANALYZE TABLE orders - 确认真实瓶颈：90%时间花在外层表扫描上？那优化子查询毫无意义；网络传输占大头？那就该压缩结果集，不是改判断逻辑
最常被忽略的是：你盯着子查询改了一小时，其实主查询的JOIN顺序或缺少覆盖索引才是真正的拖累点。
