sql-server - SQL Server - 插入事务期间性能不佳
问题描述
我有一个存储过程，它执行一个查询并将该行返回到如下变量中：
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 是否为空。如果为空，则进入 INSERT 语句，否则进入 UPDATE 语句。让我们专注于插入我知道我遇到问题的地方。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
是否有任何最佳实践可以应用并使此执行持续时间稳定？
希望你能帮我 ！！！提前致谢...
解决方案
问题可能出在聚集索引的 DbType 上。聚集索引根据键值将数据存储在表中。默认情况下，您的主键是使用聚集索引创建的。这通常是拥有它的最佳场所，但并非总是如此。例如，如果您有一个基于 NVARCHAR 列的聚集索引，则每次执行 INSERT 时，都需要找到插入新记录的正确位置。例如，如果您的表有一百万行，寄存器按字母顺序排列，并且您的新寄存器以 A 开头，那么您的聚集索引需要将寄存器从 B 移动到 Z 以将您的新寄存器放入 A 组中。如果您的新寄存器带有 Z，则移动较少数量的记录，但这并不意味着它也很好。如果您没有可让您按顺序插入新寄存器的列，
如果您想了解更多信息，请查看此Microsoft 文档
推荐阅读
- python - Python：在其他值的字典中使用匿名列表？
- javascript - 如何在javascript中只允许数字和格式值
- java - 如何将具有多个过滤条件的 if-else if 链接块代码转换为具有空检查的单个过滤条件？
- java - 如何使用 Spring Boot 进行 Getmapping("/login")？
- java - 如何改变图像的透视
- grails - 如何创建密码过期并且用户必须在不使用 Spring Security 的情况下更新他的密码？
- python - 无法在 python 中使用应用程序运行 docker 映像
- java - 如何将 postgres 脚本传输到 hsqldb 脚本？
- r - 如何通过多个变量（列）将长格式转换为宽格式数据并相互堆叠？
- jvm - 如何修复 cassandra 错误：将 Jdk 更新到 11 后出现 111