漏写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锁（常见于统计信息过期或查询计划重编译）
最危险的不是没加锁，而是加了锁却没生效；最麻烦的不是事务失败，而是事务挂着不释放——这两点在压力测试里最容易暴露，也最容易被忽略。
