触发器无法实现悲观锁，因为AFTER触发器在更新完成后才执行，INSTEAD OF触发器不持有锁且不阻塞并发事务；真正有效的是SELECT...WITH(UPDLOCK, ROWLOCK)显式加锁。
SQL Server 里用触发器做悲观锁为什么行不通
触发器本身不能实现真正的悲观锁定，因为 AFTER UPDATE 触发器在更新**已经完成之后**才执行，此时冲突早已发生；而 INSTEAD OF UPDATE 虽能拦截，但无法直接阻塞其他并发事务——它只作用于当前语句，不持有锁、不参与事务隔离控制。
- 常见错误现象：
UPDATE语句在高并发下仍出现超卖、余额负值，日志里看不到报错，但业务数据错乱 - 使用场景：想靠触发器自动加锁防止并发修改同一行（比如库存扣减、账户余额变更）
- 根本原因：触发器不是锁机制，它不改变事务的加锁行为，也不影响其他会话对同一行的
SELECT或UPDATE尝试 - 性能影响：反而增加开销——每次更新都多跑一遍触发器逻辑，还可能因触发器里再查表引发死锁
真正起作用的悲观锁写法：SELECT FOR UPDATE 的等效替代
PostgreSQL 有 SELECT ... FOR UPDATE，MySQL 在 RR 隔离级下 SELECT ... FOR UPDATE 会加行锁，SQL Server 对应的是 SELECT ... WITH (UPDLOCK, ROWLOCK) ——这才是能阻塞并发更新的关键。
- 必须在事务中使用，且
UPDATE前显式加锁：先SELECT id FROM orders WHERE id = 123 WITH (UPDLOCK, ROWLOCK)，再执行UPDATE - 参数差异：
UPDLOCK防止其他事务获取共享锁或更新锁；ROWLOCK尽量避免锁升级成页锁或表锁；缺一不可 - 兼容性注意：SQL Server 2005+ 支持，但 Azure SQL 也支持；MySQL 8.0+ 的
SELECT ... FOR UPDATE行为更接近标准，老版本可能降级为表锁 - 错误示范：
SELECT ... WITH (HOLDLOCK)是保持共享锁到事务结束，不能阻止别人更新——它防读，不防写
UPDATE 自带锁够不够？什么时候必须手动加锁
UPDATE 语句本身会加更新锁（U 锁），但在判断条件依赖其他字段时，这个锁可能来不及覆盖完整逻辑路径。比如“余额 >= 扣减金额”这个判断如果在应用层做，就完全绕过了数据库锁保护。
- 典型踩坑场景：应用先
SELECT balance FROM accounts WHERE id = 5，判断够用后再UPDATE accounts SET balance = balance - 100——中间窗口期被其他事务抢占 - 正确做法：把判断和更新合并进一条语句，用
WHERE balance >= 100，并确保该WHERE条件命中索引，否则可能锁全表 - 性能提示：如果 where 条件没走索引，
UPDLOCK可能升级为表锁，瞬间卡住所有并发更新 - 一个安全示例：
BEGIN TRAN; SELECT id FROM inventory WHERE sku = 'A123' AND qty >= 1 WITH (UPDLOCK, ROWLOCK); UPDATE inventory SET qty = qty - 1 WHERE sku = 'A123'; COMMIT;
乐观锁更适合多数 Web 场景
真要防并发更新，比硬上悲观锁更轻量、更少阻塞的做法是加版本号或时间戳字段，靠 UPDATE ... WHERE version = ? 的影响行数判断是否冲突。
- 适用条件：冲突概率低、业务能接受重试（比如用户提交表单失败后提示“数据已被他人修改”，点重试即可）
- 关键点：必须检查
ROWCOUNT或 ORM 返回的受影响行数，为 0 就说明条件不满足，不是“执行失败” - 对比悲观锁：不阻塞读、不长期占锁、无死锁风险，但需要应用层配合处理重试逻辑
- 容易忽略的细节：时间戳字段若用
GETDATE()，在同毫秒内多次调用可能重复；推荐用rowversion（SQL Server）或自增version整数
实际并发控制从来不是“选个机制就行”，而是看冲突频率、业务容忍度、数据库能力边界——悲观锁看着直接，但一旦锁范围失控或事务拖太久，反而变成系统瓶颈。
