优先用原子UPDATE+WHERE校验，避免先查后更新导致超卖；执行后检查影响行数为0即说明库存不足或已被扣减，无需加锁且不依赖隔离级别，适用于条件可直接写入WHERE的简单场景。
优先用原子 UPDATE + WHERE 校验，别写“先查后更新”
“先 SELECT 库存，再 UPDATE 扣减”看着顺，但中间存在不可控时间窗口——两个事务几乎同时查到 stock = 10，都判断“够扣”，结果双双执行 UPDATE，超卖就发生了。
原子写法直接堵死这个窗口：
UPDATE products SET stock = stock - 1 WHERE id = 1001 AND stock >= 1;
执行后立刻检查影响行数：@@ROWCOUNT（SQL Server）、ROW_COUNT()（MySQL）或 pg_affected_rows()（PostgreSQL）为 0，说明条件不满足（已售罄或被别人扣了），无需加锁、不依赖隔离级别。
- 适用于逻辑简单、判断条件能直接写进
WHERE的场景，比如“余额大于 X”“状态为pending” - 避免在浮点字段上做精确值比对（精度误差会导致条件失效）
- 如果业务需要记录修改次数或防止重复提交，再补一个
version字段做乐观锁
SQL Server 里 sp_getapplock 怎么调用才不残留锁
sp_getapplock 是轻量应用锁，但默认绑定事务——没 COMMIT 或 ROLLBACK，锁就一直挂着；连接池复用后，新请求会被静默阻塞。
正确姿势必须满足这四点：
- 锁操作必须包裹在
BEGIN TRANSACTION内，且事务结束前不能退出存储过程 -
@Resource参数要带业务上下文，例如'order_pay_' + CAST(@order_id AS VARCHAR(20))；硬编码'mylock'会锁住所有请求 -
@LockTimeout必须设具体毫秒值，比如5000；别用默认-1（无限等待） - 必须检查返回值：
IF @result < 0就表示失败（-1=超时，-2=死锁牺牲品），不能只看@@ERROR
MySQL 没有 sp_getapplock，GET_LOCK() 怎么用才安全
MySQL 没有内置应用锁函数，GET_LOCK() 是唯一跨会话的命名锁方案，但它不是事务安全的：连接断开、异常退出、或忘记调用 RELEASE_LOCK()，锁就永远留在那里。
使用时必须守住两条底线：
- 锁名要唯一稳定，推荐格式：
'db_shop_voucher_use_' + CAST(@voucher_id AS CHAR)；纯数字或固定字符串极易冲突 -
RELEASE_LOCK()必须出现在两个地方：正常流程末尾 +EXIT HANDLER异常处理器里，否则一次崩溃就可能让整条业务线卡住 -
IS_USED_LOCK()只能用于诊断，不能用来轮询等待——它本身会加锁，高并发下反而成瓶颈
什么时候该用 SELECT ... FOR UPDATE
适合写频繁、冲突高、业务要求强一致的场景，比如秒杀库存扣减、资金划账。但它的代价很高，容易引发锁升级和阻塞。
用之前确认三点：
-
WHERE条件必须命中索引，否则可能锁表（非主键字段没索引时尤其危险） - 锁持有时间越短越好：查完立刻更新并
COMMIT，避免在事务里做网络请求、日志写入等耗时操作 - 应用层需设置合理超时（如 JDBC 的
queryTimeout），防止死锁或长等待；SQL Server / PostgreSQL 中还要注意隔离级别对锁范围的影响
真正难的不是选哪种方案，而是判断“这个业务到底能不能接受重试”“失败后用户感知是否可接受”——这些决定了你该用原子更新、乐观锁，还是咬牙上悲观锁。
