SQL存储过程多线程并发数据争抢解决方法

优先使用 UPDATE ... WHERE 带条件校验，因其是原子操作，可避免超卖；仅当业务逻辑无法单条 SQL 实现时才加锁，且需规范使用事务、锁名和超时设置。

先说一个核心判断：在绝大多数并发场景下，最轻量、最可靠、也最容易被忽略的解法，其实就是 UPDATE ... WHERE 带上条件校验。不是先查再更新，而是直接让数据库替你判断——这条简单原则，真正做到的团队并不多。

为什么 UPDATE ... WHERE 比 SELECT + UPDATE 更安全

说到这个，很多团队第一反应就是“先查库存，再扣减”，对吧？逻辑上听起来似乎没问题——但别忘了，多线程场景下两个线程几乎同时执行时，都会看到 stock = 10，都判断“够扣”，然后双双执行 UPDATE。结果 stock 变成 8，超卖 2 单。这个时间窗口靠 Sleep 或重试根本堵不住。

UPDATE products SET stock = stock - 1 WHERE id = 1001 AND stock >= 1，这是一条原子操作：条件不满足，整条语句就不生效，根本不会进入“扣减逻辑”。执行完只需检查影响行数：MySQL 用 ROW_COUNT()，PostgreSQL 用 pg_affected_rows()，SQL Server 用 @@ROWCOUNT。

返回 0？说明失败，要么已被别人抢走，要么已经售罄。整个过程不需要锁、不依赖隔离级别、也不需要额外字段。干净利落。

什么时候必须加锁？怎么加才不卡死

当然，有些场景单条 UPDATE 搞不定。比如要跨多张表校验，或者调外部接口后再决定是否扣减，这才轮到锁出场。但锁这个东西，极易被滥用。

• SQL Server 的 sp_getapplock 必须包在 BEGIN TRANSACTION 里面，事务结束前不能退出存储过程，否则锁会残留。
• 锁名一定要带业务上下文，比如 'order_pay_' + CAST(@order_id AS VARCHAR(20))。如果硬编码一个 'mylock'，所有请求都会被串行化，那还不如不用。
• @LockTimeout 必须设具体毫秒值，比如 5000。别用默认的 -1，那相当于无限等待。
• 返回值必须检查：IF @result < 0 就表示失败（-1=超时，-2=死锁牺牲品）。别只盯着 @@ERROR，那个远远不够。

MySQL 怎么模拟应用级锁

MySQL 的情况比较特殊，它没有 sp_getapplock 这种事务安全的应用锁。GET_LOCK() 是唯一跨会话方案，但它本身不是事务安全的。

• 锁名必须唯一稳定，推荐格式 'db_shop_voucher_use_' + CAST(@voucher_id AS CHAR)。纯数字或固定字符串太容易冲突。
• RELEASE_LOCK() 必须出现在两个地方：正常流程末尾，以及 EXIT HANDLER 异常处理器里。否则一次崩溃就可能让锁永远挂住。
• IS_USED_LOCK() 只适合用来诊断，不要拿来轮询等待——它自己也会加锁，高并发下反而成瓶颈。

视图、临时表、自增 ID 在并发下特别容易翻车

这些数据结构看起来“只读就安全”，其实远没那么简单。

• 视图查询会真实访问基表。如果视图里包含无索引的 JOIN 或 WHERE 字段，容易触发大量 S 锁，和正在 UPDATE 的事务互相等待，直接死锁。
• 多线程用 SELECT MAX(oid) 算新 ID 插入，必然错乱——A 和 B 线程同时读到 oid=100，都插 101，结果就是主键冲突或数据错位。
• 正确的做法是建一张 max_oid 表，用 UPDATE max_oid SET current_val = current_val + N 原子获取一批连续 ID，再插入。

真正难的不是写锁，而是判断“哪一步真需要锁”。90% 的并发问题，一条带条件的 UPDATE 就能解决，剩下 10% 才轮到锁和事务设计。但多数人一上来就加锁，反而把系统拖慢。