IF EXISTS(SELECT 1 FROM ... WHERE ...)是SQL Server中判断记录存在的最优方案，因其仅查找首行、开销小，且需配合索引、避免冗余赋值和并发陷阱，同时务必使用SET NOCOUNT ON并立即读取@@ROWCOUNT。
直接用 IF EXISTS 判断记录存在性最稳妥
SQL Server 中判断某条记录是否存在，IF EXISTS(SELECT 1 FROM ... WHERE ...) 是首选方案。它不返回实际数据，只检查是否存在匹配行，开销比 SELECT COUNT(*) 或 SELECT * 小得多，尤其在大表上差异明显。
常见错误是写成 IF (SELECT COUNT(*) FROM ...) > 0 —— 这会强制扫描全部匹配行再计数，而 EXISTS 找到第一个就停，性能差一个数量级。
- 必须用
SELECT 1（或任意常量），不能省略SELECT子句 -
WHERE条件里字段要有索引，否则EXISTS也慢 - 不要在
EXISTS外层再套一层变量赋值（如DECLARE @cnt INT; SELECT @cnt = COUNT(*)...），纯属冗余
UPDATE 前先 IF EXISTS，还是直接 UPDATE 再查 @@ROWCOUNT？
两种方式都可行，但适用场景不同：
- 如果更新逻辑复杂、涉及多表或需前置校验（比如权限、状态合法性），推荐先
IF EXISTS—— 避免无谓的锁和日志写入 - 如果只是简单更新且主键/唯一键明确，可直接
UPDATE，然后用IF @@ROWCOUNT = 0判断是否没更新到行 —— 更简洁，少一次查询 -
@@ROWCOUNT必须紧跟在UPDATE后立即读取，中间插任何语句（哪怕PRINT）都会重置它
示例（直接 UPDATE + @@ROWCOUNT）：
UPDATE UserInfo SET UserPwd = @newPwd WHERE UserId = @userId;<br>IF @@ROWCOUNT = 0<br>BEGIN<br> RAISERROR('用户不存在', 16, 1);<br>END
存储过程中避免重复查同一条记录
常见陷阱：先用 IF EXISTS 判断存在，再 UPDATE —— 表面看两步，实际可能因并发导致“判断时存在，执行时已被删”。
真正安全的做法是把判断和更新合并在一个原子操作里，例如：
- 用带条件的
UPDATE，如UPDATE ... SET ... WHERE Id = @id AND Status = 'Active'，再靠@@ROWCOUNT确认是否生效 - 若业务要求严格一致性，应在事务中加
UPDLOCK提示（如SELECT ... WITH (UPDLOCK) WHERE ...），防止其他会话修改该行 - 不要在
IF EXISTS和后续UPDATE之间做耗时操作（如调用外部 API、长循环），否则窗口期放大
别忽略 SET NOCOUNT ON 对判断逻辑的影响
存储过程开头没加 SET NOCOUNT ON，会导致每个 UPDATE / INSERT 返回影响行数消息，干扰客户端对结果集的解析，尤其在嵌套调用或 ORM 场景下容易误判。
更隐蔽的问题是：@@ROWCOUNT 在某些情况下会被 PRINT、RAISERROR（不含 WITH NOWAIT）等语句意外清零 —— 而 SET NOCOUNT ON 能减少这类干扰。
- 务必在存储过程第一行写
SET NOCOUNT ON; -
@@ROWCOUNT是会话级、语句级的，不是全局变量，每条可影响行数的语句后都得立刻读 - 调试时临时关掉
NO COUNT可以看执行反馈，但上线前必须打开
EXISTS 的子查询未加索引，以及 @@ROWCOUNT 被无关语句覆盖 —— 这两个点一旦出问题，逻辑就不可靠，而且很难复现。 
