SQL存储过程如何使用锁避免重复处理-SQL-PHP中文网

绝大多数重复处理问题无需显式加锁，应优先使用带where条件的原子update；例如扣库存、改订单状态等场景，通过where校验状态（如status='pending'）并检查影响行数，可彻底避免并发重复处理。

sql存储过程如何使用锁避免重复处理

绝大多数重复处理问题，根本不需要显式加锁——用原子 UPDATE + WHERE 条件就能堵死并发窗口。比如扣库存、改订单状态、标记任务为“已处理”，只要判断逻辑能写进 WHERE，就该首选这条路。

常见错误现象：先 SELECT status FROM orders WHERE id = @id，再根据结果决定是否 UPDATE。两个事务几乎同时查到 status = 'pending'，都执行 UPDATE，结果重复处理。

UPDATE orders SET status = 'processing' WHERE id = @id AND status = 'pending' 执行后检查影响行数：@@ROWCOUNT（SQL Server）、ROW_COUNT()（MySQL）或 pg_affected_rows()（PostgreSQL）为 0，说明已被别人抢先处理，直接退出
避免在浮点字段、JSON 字段或计算表达式上做精确匹配（如 WHERE ABS(amount - @target) ），精度误差会导致条件失效
若需记录修改次数或防重提交，可补一个 version 字段做乐观锁：UPDATE ... WHERE id = @id AND version = @expected_version

sp_getapplock 不是数据库行锁的替代品，而是应用层协调工具，适用场景非常窄：同一笔订单、同一个优惠券 ID、同一条定时任务，**必须且只能被一个进程处理一次**。

常见错误现象：所有存储过程都用硬编码资源名 'order_process' 加锁，结果整个订单系统串行化，QPS 归零。

资源名必须带唯一业务标识，例如 'order_' + CAST(@order_id AS VARCHAR(20)) 或 'voucher_use_' + CAST(@voucher_id AS VARCHAR(20))
必须包裹在 BEGIN TRANSACTION 内，且锁操作前后都要有明确的 COMMIT 或 ROLLBACK，否则锁会随事务挂起，连接池复用后新请求静默阻塞
必须设 @LockTimeout（如 5000），不能依赖默认 -1（无限等待）；返回值 @result 必须检查：-1 表示超时，-2 是死锁牺牲品，不能只看 @@ERROR

SELECT ... FOR UPDATE 是真正的行级锁，但代价高、易出错。它不该用来代替原子更新，而应保留在“读取后需多次判断+分支写入”这类复杂逻辑中——比如要根据用户积分、等级、历史行为组合决策是否发放奖励。

常见错误现象：执行 SELECT * FROM users WHERE name = @name FOR UPDATE 却没在 name 上建索引，InnoDB 全表扫描并锁住所有行，等效于锁表。

调用前务必 EXPLAIN 该语句，确认 key 列非 NULL、rows 值合理；理想执行计划是 type=const 或 ref
避免在 FOR UPDATE 的 WHERE 中对字段做函数操作，如 WHERE DATE(created_at) = '2024-01-01' 会让索引失效
事务内所有路径（包括异常分支）都必须有 COMMIT 或 ROLLBACK，否则锁永不释放；建议开头加 DECLARE EXIT HANDLER FOR SQLEXCEPTION ROLLBACK;