每分钟，该程序从um DB e读取一组记录，并在另一个DB中复制它们。 99％的情况下，它由无操作组成，因为数据没有变化。
问题在于个别覆盖变得越来越慢。有2500条记录，它变得引人注目。
如果数据没有变化，为什么SQL逐渐变慢？
更多详细信息：那时候，我使用GUID作为主键（我知道的很差）。但据我所知，只有在有新插入或更新改变数据大小的情况下才会导致碎片，在这两种情况下都会导致页面拆分。我的理论是，这些nop更新会破坏某些东西（不易察觉）并导致延迟增加。也许SQL Server将此更新实现为删除/插入事务？
答案 0 :(得分：0)
碎片并不是随机GUID降低性能的唯一原因。需要更多IO，因为行在整个表中均匀分布。这通常会导致性能随着数据库大小的增加而逐渐降低，特别是对于传统的旋转介质。请记住，即使没有更新数据，也必须先将数据读入内存。使用纯随机密钥请求减少了所需行已经在内存中的页面的可能性。
如果必须使用GUID，请考虑使用NEWSEQUENTIALID或UuidCreateSequential分配的顺序值以及一些字节交换。有关代码示例以及此常见性能问题的其他详细信息，请参阅我的Improving Uniqueidentifier Performance帖子。