直接结论：必须用IF EXISTS(SELECT 1 FROM ...)代替IF (SELECT COUNT(*) FROM ...)>0；前者找到首行即终止，后者强制全量计数，性能差距可达百倍。
存储过程里用IF EXISTS代替IF (SELECT COUNT(...) > 0)
直接结论：在 IF 条件判断中，必须写成 IF EXISTS (SELECT 1 FROM ...)，而不是 IF (SELECT COUNT(*) FROM ...) > 0。后者会强制数据库扫完所有匹配行，哪怕只有一条也得数到底。
常见错误现象：
-
IF (SELECT COUNT(1) FROM users WHERE id = @uid) > 0—— 在大表或高并发下，这条语句可能成为慢查询瓶颈 - 子查询返回空结果集时，某些数据库（如 SQL Server 严格模式）会报“子查询返回多于一行”或空值警告
实操建议：
- 把原
COUNT子查询整个替换成EXISTS (SELECT 1 FROM ...)，注意保留 WHERE 中的参数引用（如@uid） - 子查询里始终用
SELECT 1，不是SELECT *或SELECT id，语义清晰且优化器更易识别短路意图 - 确保子查询中的关联字段有索引，否则
EXISTS也退化为全表扫描
跨表校验时EXISTS子查询怎么写才不漏关联条件
错误写法常出现在 JOIN 场景里：子查询忘了加主表字段的关联条件，导致逻辑错乱或性能崩溃。
例如，在验证「客户是否有未发货订单」时，下面这个是错的：
IF EXISTS (SELECT 1 FROM orders WHERE status != 'shipped')
它没和当前客户绑定，实际查的是全库是否存在未发货订单，不是「这个客户」有没有。
正确写法必须显式关联：
IF EXISTS (SELECT 1 FROM orders WHERE customer_id = @cid AND status != 'shipped')
关键点：
- 子查询的
WHERE必须包含对主查询上下文变量（如@cid）或外部表字段（如c.id）的引用 - 不要在子查询里写
JOIN，除非必要；多数情况用单表 + 关联条件更稳定、更易走索引 - 如果真要 JOIN 多表校验（比如「客户所在城市是否开通了配送服务」），务必确认 JOIN 条件完整，避免隐式笛卡尔积
NULL值校验不能混在EXISTS里一起做
EXISTS 只管“有没有行”，完全不感知 NULL。所以别指望它能替代 IS NULL 判断。
典型错误：
IF EXISTS (SELECT 1 FROM users WHERE id = @uid AND email = NULL)
这句永远不成立，因为 = NULL 永远返回 UNKNOWN，不是 TRUE。数据库不会报错，但逻辑失效。
正确做法是拆开处理：
- 存在性用
EXISTS：确认该用户记录是否存在 - 空值判断单独写：
UPDATE ... SET status = 'pending' WHERE id = @uid AND email IS NULL - 如果两者要联动（比如“用户存在且邮箱为空”），就用
AND连接两个条件，别塞进同一个子查询
EXISTS在存储过程中配合RETURN或RAISERROR使用更可控
很多开发者只用 EXISTS 做简单跳过，但忽略后续流程控制——比如校验失败时该不该中断、要不要抛错、是否要记录日志。
推荐组合用法：
- 校验失败立即
RETURN，避免后续冗余执行：IF NOT EXISTS (SELECT 1 FROM config WHERE key = 'feature_x') BEGIN RAISERROR('配置缺失', 16, 1); RETURN; END - 避免在循环体内反复调用同一
EXISTS，可提前查一次存到变量里：DECLARE @has_perm BIT = CASE WHEN EXISTS (...) THEN 1 ELSE 0 END - 不要用
EXISTS替代业务状态字段（如is_active），那是设计问题；EXISTS只适合“动态存在性”，不是“静态状态”
最常被忽略的一点：EXISTS 的执行计划是否真的走了索引查找（Seek）而不是扫描（Scan），得看实际执行计划，不能光靠写法自信。上线前务必用 SET STATISTICS XML ON 或 EXPLAIN 看一眼。
