优先用原子UPDATE+WHERE校验，因其消除“先查后更新”窗口期，避免超卖；执行后检查影响行数即可判断是否成功，无需锁、不依赖隔离级别。
SQL 存储过程中处理并发冲突，优先用原子 UPDATE + WHERE 条件校验，其次才考虑锁；盲目加 SELECT FOR UPDATE 或 sp_getapplock 很容易把系统拖慢甚至卡死。
UPDATE 带条件校验为什么比先查后更新更可靠
“先 SELECT 再 UPDATE” 看似自然，但中间存在不可控的时间窗口——两个事务几乎同时查到相同库存，都判断“够扣”，结果双双执行 UPDATE，超卖就发生了。
原子写法直接堵死这个窗口：
UPDATE products SET stock = stock - 1 WHERE id = 1001 AND stock >= 1;
执行后检查影响行数：ROW_COUNT()（MySQL）、pg_affected_rows()（PostgreSQL）或 @@ROWCOUNT（SQL Server）为 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 中模拟行级应用锁只能靠 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，什么时候该躲着走
SELECT ... FOR UPDATE 不是万能药。它适合强一致性读改写链路（如“查库存→扣减→记日志”），但代价是阻塞其他请求，尤其在 REPEATABLE READ 隔离级别下，锁会持续到事务结束。
高频队列类场景（比如任务分发、工单领取），要用 SKIP LOCKED 避免排队：
SELECT * FROM tasks WHERE status = 'pending' ORDER BY created_at LIMIT 1 FOR UPDATE SKIP LOCKED;
关键细节：
- WHERE 条件必须命中索引，否则可能升级为表锁
- 锁持有时间越短越好：查完立刻更新并
COMMIT，别在事务里做 HTTP 调用或复杂计算 - 应用层必须设置 SQL 查询超时（如 JDBC 的
queryTimeout），防止一个慢查询拖垮整个连接池
真正难处理的不是锁本身，而是锁和业务生命周期错位——比如锁了订单，但下游支付回调失败，事务不敢提交，锁就一直占着。这类问题没法靠换隔离级别或加锁函数解决，得从流程设计上拆解原子性边界。
