【问题标题】:Performance difference between Primary Key and Unique Clustered Index in SQL ServerSQL Server 中主键和唯一聚集索引之间的性能差异
【发布时间】:2012-07-18 17:06:18
【问题描述】:

我们有 2 个大约有 40M 行的表。数据库大小约为 20GB,大部分用于这 2 个表。每天,我们需要删除一些数据,即大约 10M 行。因此,我们使用批量删除来将日志文件保持在一定大小。

最初,表没有主键。但是每个表都有唯一的聚集索引。删除需要永远。即删除虚拟机上的 500K 行大约需要 2-3 小时。 * 删除前,索引已重建。

现在,我们将唯一的聚集索引转换为主键。删除 2M 行大约需要 20-30 分钟。

我知道主键和唯一聚集索引之间存在差异,但为什么性能差异如此之大?

有人有见解吗?

谢谢

【问题讨论】:

  • 从技术上讲,如果两者都被声明为聚集索引并且在相同的列上,则不应该有任何差异。您是否看到这两种不同方法产生的计划有任何差异?一个明显的问题,但仍然在问,PK 是否与唯一聚集索引在同一列上?另外,为什么要在删除唯一聚集索引之前创建索引?如果数据删除中存在某种模式,请尝试使用分区表..
  • 我很好奇将要保留的集合插入到新表中是否有益,然后将 TRUNCATE 您的父表插入以节省日志记录。
  • 查询计划有什么不同?另外,主索引是否也是集群的(默认情况下是集群的,除非您指定 NONCLUSTERED)?
  • 你试过非Clustered Index吗?原因是 - non clustered index 保留 Row locator id 信息和 Clustered index keeps complete row info. second point is did you check it directly at the machine instead of the Virtual machine, because it depends how much RAM` 被分配给 Virtual machineaccess time 取决于 RAM
  • delete 语句使用哪种 where 子句?还是根本没有 where 子句?

标签: sql sql-server sql-server-2008


【解决方案1】:

滚动我的 8 球:如果您声明了一个 非集群 主键(正如您的帖子中所暗示的那样),那么在每批中您很可能会点击 index tipping point。因此,每个批次都会对 40M 行进行全面扫描以删除批次大小。然后,在下一批中,再次进行全面扫描。依此类推,直到您的 10M 被删除。使用集群键,批次应该只扫描被删除的实际行(当然我假设您的批量删除条件实际上会使用集群键......)。如您所见,当一个人开始猜测...

时会有很多未知数

但最终...您有一个性能问题,您应该使用性能故障排除技术进行调查。捕获执行计划,wait statsstatistics io。遵循Waits and Queues 之类的方法。措施。不要听互联网上刚刚推出8-Ball的人的guesses...

【讨论】:

  • 他提到,在他的案例中,聚集索引的表现非常糟糕,但 PK 表现更好(我假设它是聚集的,因为他没有提到他将其声明为非聚集索引)跨度>
  • 是的,PK是集群的。该索引是唯一的,聚集的。我认为他们不应该在速度上有太大差异。但是,它有。我测试了很多次。可能是因为测试中的数据吗?
  • 这些计划是一样的吗?另外,当您说性能不一样时,您测量的是什么,IO's,cpu time 或 elapsed time?
【解决方案2】:

您可以尝试在删除之前删除索引,然后再重新添加。如果我没记错的话,每次删除后都会重新组织索引;这需要额外的时间。

【讨论】:

  • 你的意思是PK不需要重组?将尝试删除索引以查看速度如何。但是,如果我们删除后重新组织索引,我相信日志文件的大小会很快增长,这是我们最初尝试处理的问题。
  • PK 也应该是一个索引...我过去使用过这个技巧(删除/重新添加索引)并且能够在插入/删除时获得更好的性能结果,所以我想如果您别无选择,它值得一试。但是这种方法是最后的手段......我认为如果您可以为您正在使用的两个表、索引和查询发布表模式,您可能可以获得更多帮助。不要将它们发布到 cmets 中,而是更新您的帖子,使其更具可读性。
【解决方案3】:

我想这可能是因为您的索引在一次删除操作之前非常碎片化,但在另一次删除操作之前却没有。聚集唯一索引的碎片化程度如何?在删除之前对所有索引进行重建后,您可以查看运行时是否仍然存在差异,例如ALTER INDEX ALL ON blah REBUILD

您在创建唯一聚集索引时使用了哪些选项(特别是以下设置为:PAD_INDEX、STATISTICS_NORECOMPUTE、SORT_IN_TEMPDB、IGNORE_DUP_KEY、ALLOW_ROW_LOCKS 和 ALLOW_PAGE_LOCKS)?

【讨论】:

    猜你喜欢
    • 2016-09-05
    • 1970-01-01
    • 1970-01-01
    • 2013-10-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多