索引的表被搞砸了，这会导致查询花费很长时间来获取行

Question

我有一个表A [Schema: key_id, x,y,z,...]，其中的键ID列是唯一的，并且增量播种为1.现在我有一个表B [schema: key_id, key_idOfA, x,y,z,....]其中是具有类似模式的A的备份（仅差异表B具有其自己的key_id并且它也保持表A的原始key_id）。

我有一个服务，基于where子句从A传输一些行到B.我试过这个服务一次，它通过将行从A传送到B可以很好地工作。现在再次检查这个服务，我必须将行（key_idOfA，x，y，z，...）从B传送回A.

以免丢失表A的原KEY_ID在这里我第一次使用

SET IDENTITY_INSERT A ON 

并转移其工作的罚款行。转让完成后我用

SET IDENTITY_INSERT A OFF 

现在，当我再次运行该服务需要花费大量的时间来得到这会导致超时表几行。准确地说，在SQL Server Management Studio上需要5分钟才能获得30,000行。从服务中，由于超时3分钟，查询超时。

我知道切换表的身份插入ON和OFF是一种不好的做法，但这是一个测试床DB，我绝不会在生产数据库上做它。

我的问题：

1. 是索引搞砸由于该查询花费这么多的时间？还是有其他问题？

2. 我可以采取不同的方法来将行传回来而不会搞乱索引吗？

Answer 1

那么，你可以做什么来看看为什么它很慢，看看实际查询计划。 在SSMS中，这是通过顶部的查询菜单，选择实际查询计划（或CTRL-M） 当您运行查询后，您会在结果和消息选项卡旁边获得一个额外的选项卡。它被称为执行计划。 当你仔细观察，你必须从最右侧开始。这是查询开始的地方。寻找高百分比。如果您看到索引扫描或表扫描，那么索引扫描会更糟糕，这是一种更快的方法。

如果您发现表格/索引扫描的百分比较高，请尝试对您的索引进行碎片整理。

你可能想看看剧本我写的磁盘碎片整理的索引：www.plixa.nl/fragment-an-index

希望它能帮助，如果没有，让我们知道:)