sp_getapplock必须在显式事务中使用，否则锁立即释放失效；需校验返回值、规范锁名设计、确保所有路径（含异常和RETURN）均调用sp_releaseapplock。
sp_getapplock 是 SQL Server 提供的轻量级应用层锁机制，不依赖表或行资源，适合控制存储过程级别的串行执行。它不是万能锁，用错反而引发阻塞或死锁。
为什么不能直接用 sp_getapplock 包裹整个业务逻辑？
因为 sp_getapplock 的作用域是会话（session）+ 数据库上下文，且锁在事务提交/回滚后自动释放——但如果你没显式开启事务，锁会在语句执行完立刻释放，起不到互斥效果。
- 常见错误：在无
BEGIN TRANSACTION的存储过程中调用sp_getapplock，然后直接执行 INSERT/UPDATE，结果锁早已释放，后续并发请求照样闯入 - 正确做法：必须把加锁、业务逻辑、释放锁三者包进同一个显式事务中
- 注意：锁名（
@Resource）区分数据库上下文，跨库调用需确保在目标库中执行sp_getapplock
sp_getapplock 返回值必须检查，不能只看是否为 0
它的返回值不是布尔，而是状态码，不同值代表完全不同的语义：
-
0：成功获取锁（立即或等待后） -
-1：超时（@LockTimeout耗尽），此时应决定是重试、报错还是跳过 -
-2：死锁牺牲品（当前会话被选为 deadlock victim） -
-3：参数错误（如空锁名、非法模式） -
-999：锁名长度超过 255 字节（SQL Server 实际限制，文档未明说但实测触发）
示例判断逻辑：
EXEC @result = sp_getapplock @Resource = 'my_proc_batch_123', @LockMode = 'Exclusive', @LockTimeout = 30;
IF @result < 0
BEGIN
IF @result = -1 RAISERROR('Lock timeout on batch 123', 16, 1);
ELSE RAISERROR('App lock error: %d', 16, 1, @result);
RETURN;
END锁名设计不当会导致误互斥或漏互斥
硬编码锁名（如 'proc_lock'）等于给所有调用贴同一张门牌，不管参数、租户、批次，全被堵死；而动态拼接太宽泛（如只含存储过程名），又失去隔离粒度。
- 推荐格式：
CONCAT('proc_', @proc_name, '_', @tenant_id, '_', @batch_id)，确保业务维度唯一 - 长度务必 ≤ 255 字节，超长会被截断——两个不同参数组合可能生成相同锁名，造成隐性冲突
- 避免空格、点号、斜杠等特殊字符，SQL Server 内部解析可能出问题
- 不要在锁名中拼接用户输入原文，需先做
REPLACE清洗（如去换行、制表符）
释放锁必须覆盖所有路径，包括异常分支
sp_releaseapplock 不会自动触发，也不会随连接关闭而释放（除非会话断开且锁未被显式释放，此时由 SQL Server 异步清理，但不可靠）。
- 必须在
TRY块末尾和CATCH块开头都调用sp_releaseapplock - 不能依赖
COMMIT或ROLLBACK自动释放——它们只影响事务锁，不影响sp_getapplock创建的应用锁 - 更危险的是：如果存储过程里有
RETURN提前退出，且之前没释放锁，该锁将一直挂在会话上，直到超时（默认 60 秒）或会话终结
最稳妥结构：
BEGIN TRY
BEGIN TRANSACTION;
EXEC @r = sp_getapplock ...;
IF @r < 0 THROW ...;
-- 业务逻辑
EXEC sp_releaseapplock @Resource = ...;
COMMIT TRANSACTION;
END TRY
BEGIN CATCH
EXEC sp_releaseapplock @Resource = ...;
ROLLBACK TRANSACTION;
THROW;
END CATCH真正容易被忽略的是锁名的业务语义一致性——它不是技术标识，而是业务契约。改一个参数字段却忘了同步更新锁名拼接逻辑，就会让本该互斥的流程并行跑起来，或者让本可并行的流程被错误阻塞。这没法靠测试全覆盖，得靠代码审查和命名规范卡住。
