SQL Server中主键与唯一聚集索引的性能差异
我们有两个表，大约有40M行。数据库的大小约为20 of，大部分用于这两个表。每天，我们需要删除一些数据，即大约10M行。因此，我们使用批量删除将日志文件保持在一定的大小内。
最初，表没有主键。但是对于每个表都有唯一的聚集索引。删除操作将永远进行。即删除一个虚拟机上的500K行大约需要2-3个小时。* delete前，已重建索引。
现在，我们将唯一的聚集索引转换为主键。删除2M行大约需要20-30分钟。
我知道主键和唯一聚集索引是有区别的，但是为什么性能会如此不同呢？
有谁有什么见解吗？
谢谢
回答 3
Stack Overflow用户
发布于 2012-07-19 01:45:58
滚动我的8球:如果您声明了一个非集群主键(从您的帖子中似乎可以看出)，那么在每一批中，您都很可能命中index tipping point。因此，每个批处理将执行40M行的完整扫描，以删除批处理大小。然后，在下一批中，再次进行全面扫描。依此类推，直到你的10M被删除。使用聚集键，批处理应该只扫描被删除的实际行(当然，我假设您的批删除条件实际上会使用聚集键...)。如你所见，当一个人开始猜测的时候，有很多未知的东西...
但最终..。您有一个性能问题，应该使用性能故障排除技术对其进行调查。捕获执行计划、wait stats、statistics io。遵循像Waits and Queues这样的方法。测量。不要听互联网上刚刚推出8-Ball的人的guesses ...
Stack Overflow用户
发布于 2012-07-19 02:23:45
您可以尝试在删除之前删除索引，然后在删除后重新添加它。如果我没记错的话，索引将在每次删除后重新组织；这需要额外的时间。
Stack Overflow用户
发布于 2014-07-09 05:38:49
我可以想象一下，在一个delete操作之前，您的索引非常零碎，但在另一个操作之前就不是了。聚集的唯一索引有多零碎？您可以查看在执行delete之前对所有索引执行重建后，运行时是否仍有差异，例如ALTER INDEX ALL ON blah REBUILD
在创建惟一的聚集索引时，您使用了哪些选项(具体地说，以下设置为: PAD_INDEX、STATISTICS_NORECOMPUTE、SORT_IN_TEMPDB、IGNORE_DUP_KEY、ALLOW_ROW_LOCKS和ALLOW_PAGE_LOCKS)？
https://stackoverflow.com/questions/11546688
复制相似问题
腾讯云开发者
