我们有2个包含大约40M行的表。数据库的大小约为20GB，大部分是针对这两个表。每天，我们需要删除一些数据，即大约10M行。所以，我们使用批量删除来保持日志文件的大小。SQL Server中主键和唯一聚簇索引之间的性能差异
最初，表中没有主键。但是每个表格都有唯一的聚集索引。删除需要永远。即在虚拟机上删除500K行大约需要2-3小时。 *在删除之前，索引被重建。
现在，我们将唯一的聚集索引转换为主键。大约需要20-30分钟才能删除2M行。
我明白主键和唯一聚集索引之间存在差异，但为什么性能如此不同？
任何人都有一些见解？
感谢
滚动我的8号球：如果你宣布非聚集主键（因为它似乎从您的文章建议），则每批你很可能击中了index tipping point。因此，每个批次将执行40M行的完整扫描以删除批量大小。然后，在下一批中，再次进行全面扫描。等到你的10M将被删除。使用聚簇键时，批次应该只扫描被删除的实际行（当然，我认为你的批量删除标准实际上使用聚簇键......）。正如你所看到的，当你开始猜测时，有很多未知数 ...
但最终......你有一个性能问题，你应该使用性能故障排除技术进行调查。捕获执行计划，wait stats，statistics io。遵循像Waits and Queues这样的方法。测量。不要在互联网上收听guesses，只需要滚动8-Ball ...
他已经提到，在他的案例中，聚集索引表现非常糟糕，但PK表现更好（并且我认为它是聚集的，因为他没有提到他宣称它是非聚集索引） – 2012-07-18 17:54:38
是的，PK是聚集的。该索引是唯一的，成簇的。我认为他们在速度上应该没有太大的差别。但是，它已经。我经过多次测试。是否可以因为测试中的数据？ – urlreader 2012-07-18 22:43:08
你有没有比较两个计划？ – 2012-07-21 17:39:46
您可以尝试在删除之前删除索引，然后重新添加它。如果我没有弄错，索引将在每次删除后重新组织;这需要额外的时间。
你的意思是PK不需要重组？将尝试删除索引，看看它的速度如何。但是，如果我们在删除后重新组织索引，我相信日志文件的大小会迅速增长，这是我们尝试处理的最初问题。 – urlreader 2012-07-18 22:46:53
PK也应该是一个索引...我过去曾经使用过这个技巧（删除/重新添加索引），并且能够在插入/删除时获得更好的性能结果，所以如果你是出于选择。但是这种方法是最后的手段......我想如果你可以为你正在使用的两个表，索引和查询发布表模式，你可能会得到更多的帮助。不要将它们发布到评论中，而是更新您的帖子，使其更具可读性。 – 2012-07-19 15:16:02
我想它可能是像你的索引是非常分散的一个删除操作之前，但不是在另一个之前。聚集独特索引有多碎片？你可以看到，如果还有这样一个重建所有索引之前的东西，如ALTER INDEX ALL ON blah REBUILD
你创建唯一聚集索引（具体是什么，有以下设置时使用何种选项删除后运行一个区别：PAD_INDEX ，STATISTICS_NORECOMPUTE，SORT_IN_TEMPDB，IGNORE_DUP_KEY，ALLOW_ROW_LOCKS和ALLOW_PAGE_LOCKS）？
我很好奇，如果插入想要保存到新表中的集合，然后'TRUNCATE'你的父表保存日志。 – Kermit 2012-07-18 17:20:56
查询计划有什么不同？另外，主索引是否也是聚集的（除非您指定了NONCLUSTERED，否则它是默认的）？ – 2012-07-18 17:22:46
您是否尝试过使用非集群索引？原因是 - “非聚集索引”保持“行定位符ID”信息和“聚集索引保持完整的行信息。第二点是你是直接在机器上而不是“虚拟机器”上检查它，因为它取决于'虚拟机'分配了多少'RAM'，'访问时间'取决于'RAM'。 – 2012-07-18 17:24:22