我有一个存储过程，该存储过程执行查询并将该行返回到如下所示的变量中：
SELECT @item_id = I.ID, @label_ID = SL.label_id,
FROM tb_A I
LEFT JOIN tb_B SL ON I.ID = SL.item_id
WHERE I.NUMBER = @VAR
我有一个IF检查@label_ID是否为null。如果为null，则转到INSERT语句，否则转到UPDATE语句。让我们专注于INSERT，我知道我遇到了问题。 INSERT部分如下：
IF @label_ID IS NULL
BEGIN
INSERT INTO tb_B (item_id, label_qrcode, label_barcode, data_leitura, data_inclusao)
VALUES (@item_id, @label_qrcode, @label_barcode, @data_leitura, GETDATE())
END
因此，tb_B在ID列中有一个PK，在item_ID列中有一个FK，它引用了tb_A表中的列ID。
我运行SQL Server Profiler，发现有时此存储过程的持续时间约为2300毫秒，而正常平均时间为16毫秒。
我运行了“执行计划”，而最大的花费是在“聚集索引插入”组件中。显示如下：
有关表格的更多详细信息：
tb_A Storage:
Index space: 6.853,188 MB
Row count: 45988842
Data space: 5.444,297 MB
tb_B Storage:
Index space: 1.681,688 MB
Row count: 15552847
Data space: 1.663,281 MB
Statistics for INDEX 'PK_tb_B'.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Name Updated Rows Rows Sampled Steps Density Average Key Length String Index
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
PK_tb_B Sep 23 2018 2:30AM 15369616 15369616 5 1 4 NO 15369616
All Density Average Length Columns
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
6.506343E-08 4 id
Histogram Steps
RANGE_HI_KEY RANGE_ROWS EQ_ROWS DISTINCT_RANGE_ROWS AVG_RANGE_ROWS
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1 0 1 0 1
8192841 8192198 1 8192198 1
8270245 65535 1 65535 1
15383143 7111878 1 7111878 1
15383144 0 1 0 1
Statistics for INDEX 'IDX_tb_B_ITEM_ID'.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Name Updated Rows Rows Sampled Steps Density Average Key Length String Index
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
IDX_tb_B_ITEM_ID Sep 23 2018 2:30AM 15369616 15369616 12 1 7.999424 NO 15369616
All Density Average Length Columns
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
6.50728E-08 3.999424 item_id
6.506343E-08 7.999424 item_id, id
Histogram Steps
RANGE_HI_KEY RANGE_ROWS EQ_ROWS DISTINCT_RANGE_ROWS AVG_RANGE_ROWS
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
0 2214 0 1
16549857 0 1 0 1
29907650 65734 1 65734 1
32097131 131071 1 131071 1
32296132 196607 1 196607 1
32406913 98303 1 98303 1
40163331 7700479 1 7700479 1
40237216 65535 1 65535 1
47234636 6946815 1 6946815 1
47387143 131071 1 131071 1
47439431 31776 1 31776 1
47439440 0 1 0 1
是否有最佳实践可以应用并使该执行持续时间稳定？
希望您能帮助我！！！ 预先感谢...
答案 0 :(得分：-1)
问题可能出在聚集索引的DbType上。聚集索引基于键值将数据存储在表中。默认情况下，您的主键是使用聚簇索引创建的。这通常是拥有它的最佳地点， 但不总是。例如，如果您在NVARCHAR列上具有聚集索引，则每次执行INSERT时，都需要找到正确的位置来插入新记录。例如，如果您的表有100万行，并且寄存器按字母顺序排列，并且新寄存器以A开头，则聚集索引需要将寄存器从B移到Z，以将新寄存器放入A组。如果您的新寄存器以Z开头，则移动的记录数会减少，但这并不意味着它也可以。如果没有可让您顺序插入新寄存器的列，则可以为此创建一个标识列，或者使另一个列在逻辑上与输入的任何交易在逻辑上都是顺序的，而与系统无关，例如，注册的datetime列插入时发生时间。
如果您需要更多信息，请选中此Microsoft documentation
