在数据库表中使用SPID（而不是表变量）

用于预订事物的交易数据库...

我们的供应商被要求用@tablevariables替换#temptables（由于繁重的编译锁），但他们替换为一个实际表，该表将SPID作为列添加，以确保存储过程仅作用于适用的行。

您认为这种操作方法有任何风险吗？在所有事务都隔离在它们自己的事务中之前，我担心我们最终可能会将该表锁定一堆，但他们的意见是SQL使用行级锁定并且不会创建更多的锁。

SQL Server版本：2016 Enterprise-13.0.5216.0

CREATE TABLE dbo.qryTransactions (
    ID int IDENTITY (0,1) NOT NULL CONSTRAINT pk_qryTransactions PRIMARY KEY CLUSTERED,
    spid int NOT NULL,
    OrderID int,
    ItemID int,
    TimeTransactionStart datetime,
    TimeTransactionEnd datetime,
...other fields
    )

CREATE INDEX idx_qryTransactions_spidID ON qryTransactions (spid, ID) INCLUDE (ItemID, OrderID, TimeTransactionStart, TimeTransactionEnd)

杂乱无章的内容超出了注释块的范围...并且想突出显示OP为回应Ray的回答而做出的注释：

• 父proc（Common_InsertOrders_1）创建一个临时表
• 子proc（InsertOrders）查询临时表
• 正在为子proc（InsertOrders）查看编译锁

稍微切线一分钟...在这种情况下将发生Sybase ASE ...

• 每个临时表都有一个唯一的对象ID（当然，该对象ID可以在某个时候重用，但这很少见，并且对于并发会话肯定不会发生）
• Sybase ASE通常会在子proc的每次执行中强制执行重新编译，因为临时表的对象ID 发生了变化
• 如果Sybase ASE在存储的proc调用之间发现临时表的结构已更改（例如，不同的列数，不同的列名/数据类型/可空性），则Sybase ASE还将强制重新编译子proc。
• Sybase ASE的较新版本具有一种配置，该配置（有效地）告诉编译器忽略临时表对象ID的更改，从而消除了对子proc的重新编译（注意：如果表结构发生更改，仍将进行重新编译）

回到OP的问题（子proc上的编译锁定）...

• 是否有一些Sybase ASE行为的痕迹仍然存在于SQL Server中（从这两种产品成为豆荚的时候开始）？
• 是否有任何SQL Server配置可以减少（消除）子proc的重新编译（如果由于对象ID的更改）？
• OP每次可以验证父proc是否使用相同的确切结构/ DDL创建临时表吗？

至于我们考虑使用一个单一的永久表@@ SPID在会话之间区分各行的......在那里，看到... 呸 ; 重复出现的问题：

• 如何/何时清理孤立行
• 如果存在孤立数据（或在孤立数据的清理过程中，例如，删除@@ SPID = 10但有一个与@的新的/当前的/活动的会话，则数据库引擎重复使用@@ SPID可能导致数据准确性问题。 @ SPID = 10 =>清理会删除太多数据）
• 从行锁到页/表锁的升级潜力
• 如果表中有索引，则在更新索引时可能（b）锁定
• 根据表所在的数据库，您可能正在查看用于写入日志设备的更多活动（在Sybase ASE中，可以有效地禁用tempdb中的日志记录）
• 甚至行级（排他）锁也可以阻止其他会话（取决于隔离级别以及会话是否可以扫描/跳过所述排他锁）

我想回过头来（重新）研究根本问题（子proc上的重新编译锁），看看是否有办法减少（消除？）所说的编译锁。[不幸的是，我对这些问题的SQL Server知识是... NULL ...，所以会对一些SQL Server编译器专家的输入感兴趣。]

在我看来，使用@@SPID这样的方式会带来麻烦。

会话ID经常被重用；一旦用户连接注销，该会话ID便可以再次使用，并且很可能在下一个尝试连接的会话中使用。

为了使它至少半可靠地工作，您需要一个登录触发器，该触发器将使用table清除表中的先前行@@SPID。如果这样做，则使用该@@SPID列可能会在表上看到很多锁定。

SQL Server确实使用行锁定，但是它也使用页面锁定和表锁定。当然，您可以通过良好的索引来减轻这种情况，但是对我来说，这仍然像是一种反模式。

如果存储过程是用于访问受影响的表的唯一方法，则可以使用应用程序锁进行调查，从sp_getapplock本质上序列化对相关部分的访问。sp_getapplock的文档在这里。 Erik Darling 在这里有一篇有趣的文章。

是的，我确实看到了风险。使用行锁定来指望SQL是幼稚的。例如，我很确定插入和删除操作至少会使用页锁。SQL Engine根据多种因素选择锁定类型，这些因素中没有一个包含“他们的意见”。将临时表更改为表变量之类的一揽子解决方案通常也不是好主意。表变量在某些情况下非常有用，但确实存在局限性和性能问题。在大多数情况下，我更喜欢临时表。特别是当表将容纳几十行时。我将要求供应商解释为什么系统经历“繁重的编译锁”以及性能下降的原因。请记住，每当您看到时，都会发现某种“重型锁”。这并不一定意味着锁是一个问题。马克斯 关于@@ SPID的评论也很重要。此外，事务处理模型和错误处理可能是大问题。如果您的系统遇到死锁或输入数据质量问题，则标准错误处理可能会导致会话终止而没有正确重置qryTransactions表。IMO对原始问题的错误解决方法。