基于MS SQL Server的sp_getapplock实现应用单实例的技术疑问

现有一款不支持水平扩展的定时执行应用，多实例并发运行会导致状态损坏。计划通过应用层逻辑防止多实例并发，考虑采用基于MS SQL Server的分布式锁实现，其底层依赖sp_getapplock存储过程。拟将整个应用执行周期（约15分钟）作为临界区，以Session而非Transaction作为锁所有者，避免长事务。现咨询：

1. 该方案对SQL Server实例性能是否有影响？
2. 是否会导致其他应用/查询出现延迟或死锁？
3. 长时间持有锁是否会占用数据库资源影响其他请求？

问题解答 #

1. 对SQL Server实例性能的影响 #

sp_getapplock是SQL Server专为分布式场景设计的轻量级应用层锁，本身性能开销极低。它仅在内存中维护锁的元数据，不会像表锁、行锁那样占用大量存储引擎资源。

15分钟的持有时间虽然不算短，但只要锁的并发竞争频率低（比如只有你的定时应用实例在争抢这个锁），对SQL Server整体性能几乎没有可感知的影响。只有当大量会话同时尝试获取该锁时，才会产生少量锁等待开销，但这种情况在定时应用场景下很少出现。

2. 是否会导致其他应用/查询的延迟或死锁 #

• 延迟：只有当其他会话也调用sp_getapplock请求同一个锁资源（即相同的@Resource参数值）时，才会出现等待延迟。如果你的其他应用、查询不涉及这个特定锁资源，完全不会受到影响。
• 死锁：死锁的前提是两个会话互相持有对方需要的资源。由于你用的是独立的应用锁资源，和其他业务操作的行锁、表锁没有交集，除非定时应用在持有锁的同时争抢其他业务锁，且其他业务会话又在争抢这个应用锁，否则几乎不可能触发死锁——这种交叉争抢的场景在常规定时任务里很难出现。

3. 长时间持有锁的资源占用情况 #

以Session作为锁所有者时，锁会绑定到数据库会话上，而非事务，占用的资源非常有限：

• 仅占用少量内存存储锁的所有者、资源名称、超时时间等元数据，不会占用磁盘资源。
• 只要会话保持活跃（定时应用运行期间不主动断开数据库连接），锁就会持续持有，不会额外消耗CPU或IO资源。
• 需要注意：如果应用实例异常崩溃，数据库会话可能不会立即释放锁。此时可依赖SQL Server默认30分钟的会话超时机制自动清理失效的锁，也可以在应用启动时添加锁的超时检查逻辑，避免锁长期占用。

内容的提问来源于stack exchange，提问作者Enrico Massone