漏写WHERE会导致全表更新，必须用SET XACT_ABORT ON+TRY/CATCH防护，并配合UPDLOCK+HOLDLOCK加锁及高并发测试验证。

UPDATE语句漏写WHERE条件会直接全表更新

SQL Server不会阻止你执行没有WHERE子句的UPDATE，它会安静地把整张表所有行都改掉——比如UPDATE Users SET Status = 'Inactive'没加WHERE，全员失活。这不是语法错误，是逻辑灾难。

这种操作一旦在生产环境跑出，几乎没有回滚窗口：事务日志可能来不及备份，ROLLBACK只对当前未提交事务有效，而很多人习惯用SSMS直接执行、不显式开事务。

• 别依赖“我手快不会错”——误操作常发生在疲劳、复制粘贴、变量未赋值导致WHERE @id IS NOT NULL恒为真等场景
• SSMS默认不开启SET NOCOUNT ON和SET XACT_ABORT ON，出错时可能只报错但不中断，后续语句继续执行
• 即使开了事务，如果忘记COMMIT或ROLLBACK，连接挂起后锁长期持有，引发阻塞链

用SET XACT_ABORT ON + BEGIN TRY/CATCH构建防护层

仅靠BEGIN TRANSACTION不够。必须强制失败即中止，且确保异常时能清理资源。关键不是“怎么写事务”，而是“怎么让错误无法穿透”。

SET XACT_ABORT ON会让大多数运行时错误（如主键冲突、转换失败）自动触发事务回滚，而不是只回滚出错语句；配合TRY/CATCH可捕获WHERE为空、参数为NULL等业务逻辑错误。

• 在存储过程或脚本开头立即设置：SET XACT_ABORT ON; SET NOCOUNT ON;
• 所有UPDATE必须包裹在BEGIN TRY ... END TRY / BEGIN CATCH ... END CATCH中
• 在CATCH块里检查@@ROWCOUNT：若为0或远超预期（如预计改1行，实际改了10万行），立刻ROLLBACK并抛出自定义错误
• 避免在TRY块内做SELECT后再UPDATE——这属于“交错读取和更新”，易被其他事务干扰，应改用UPDATE ... FROM或CTE一次性完成

用UPDLOCK + HOLDLOCK提前锁定目标范围

当UPDATE依赖前置查询结果（例如先查余额再扣款），漏写WHERE只是表象，深层问题是并发下数据状态已变。此时光靠事务隔离级别不够，需主动加锁控制读写顺序。

UPDLOCK告诉SQL Server：“我要读的这些行，接下来大概率要更新”，它会申请更新锁而非共享锁，阻止其他事务同时获取UPDLOCK或X锁；HOLDLOCK等价于SERIALIZABLE提示，让锁持续到事务结束，防止幻读。

• 正确写法：SELECT id, balance FROM Accounts WITH (UPDLOCK, HOLDLOCK) WHERE id = @account_id
• 不要写成SELECT ... FROM ... WITH (NOLOCK)再UPDATE——那是自欺欺人，脏读+全表更新风险加倍
• 注意锁粒度：UPDLOCK在行级生效，但如果WHERE条件无索引，SQL Server可能升级为页锁甚至表锁，反而放大影响
• 测试时务必用高并发压测：单用户没问题，10个并发同时执行同一段逻辑，UPDLOCK是否真能互斥？

上线前必须验证的三件事

防护机制写得再严密，没经过真实校验等于没设。很多团队卡在“以为自己防住了”，其实只防住了教科书式错误。

• 手动删掉WHERE子句，运行脚本——看是否被TRY/CATCH捕获、是否ROLLBACK、是否记录告警日志
• 用DBCC OPENTRAN检查长时间未提交事务：隐式事务模式（SET IMPLICIT_TRANSACTIONS ON）开着却忘了COMMIT，会导致锁堆积，连SELECT都卡住
• 查sys.dm_exec_sessions和sys.dm_tran_locks，确认你的UPDLOCK请求确实拿到了U锁，而不是降级为S锁（常见于统计信息过期或查询计划重编译）

最危险的不是没加锁，而是加了锁却没生效；最麻烦的不是事务失败，而是事务挂着不释放——这两点在压力测试里最容易暴露，也最容易被忽略。