我们有 2 个大约 40M 行的表。数据库大小约为 20GB，大部分用于这 2 个表。每天，我们需要删除一些数据，即大约 10M 行。因此，我们使用批量删除将日志文件保持在一定大小。
最初，该表没有主键。但是每个表都有唯一的聚集索引。删除需要永远。即在虚拟机上删除 500K 行大约需要 2-3 个小时。* 删除前，索引已重建。
现在，我们将唯一的聚集索引转换为主键。删除 2M 行大约需要 20-30 分钟。
我知道主键和唯一聚集索引之间存在差异，但为什么性能如此不同？
有人有一些见识吗？
谢谢
问问题
9332 次
3 回答
6
滚动我的 8 球：如果您声明了一个非集群主键（正如您的帖子中所暗示的那样），那么在每批中，您很可能会达到索引临界点。因此，每个批次都会对 40M 行进行全面扫描以删除批次大小。然后，在下一批中，再次进行全面扫描。依此类推，直到您的 10M 被删除。使用集群键，批次应该只扫描被删除的实际行（当然我假设您的批量删除条件实际上会使用集群键......）。如您所见，当人们开始猜测时，会有很多未知数...
但最终......您有一个性能问题，您应该使用性能故障排除技术进行调查。捕获执行计划、等待统计信息、统计信息 io。遵循Waits 和 Queues 之类的方法。措施。不要听互联网上刚刚投出8 球的人的猜测...
于 2012-07-18T17:45:58.443 回答
1
I imagine it could be something like your index was very fragmented before one delete operation but not before another. How fragmented was the clustered unique index? You could see if there is still a difference in runtime after doing a rebuild on all indexes before the delete with something like ALTER INDEX ALL ON blah REBUILD
What options did you use when creating your unique clustered index (specifically what are the following set to: PAD_INDEX, STATISTICS_NORECOMPUTE, SORT_IN_TEMPDB, IGNORE_DUP_KEY, ALLOW_ROW_LOCKS, and ALLOW_PAGE_LOCKS)?
于 2014-07-08T21:38:49.000 回答
1
您可以尝试在删除之前删除索引，然后再重新添加。如果我没记错的话，每次删除后都会重新组织索引；这需要额外的时间。
于 2012-07-18T18:23:45.333 回答