将newid（）更改为现有表上的newsequentialid（）

目前我们有许多使用主键上的newid（）的表。这导致大量的碎片。所以我想改变列来使用newsequentialid（）来代替。将newid（）更改为现有表上的newsequentialid（）

我想现有的数据将保持相当分散的状态，但新数据的分散性较差。这意味着我应该等待一段时间，然后再将PK索引从非群集更改为群集。

我的问题是，有没有人有这样做的经验？有什么我忽略了我应该小心吗？

2009-05-27 cbp

如果您切换到sequentialguids 和重新组织一次索引，您将消除碎片。我不明白你为什么要等到零碎的页面链接在连续的范围内重新排列。

这就是说，你有没有做过任何测量，以表明碎片实际上正在影响你的系统？只是看一个索引，看到'分散75％'而不是意味着访问时间受到影响。还有更多因素起作用（缓冲池页面预期寿命，读取率与写入率，顺序操作的位置，操作的并发性等）。虽然从guid切换到顺序guid通常是安全的，但您仍然可能会引入问题。例如，您可以看到插入密集型OLTP系统的页面锁定争用，因为它会在插入点积累时创建一个热点页面。

来源

2009-05-27 01:45:41

感谢雷木思 - 有趣的评论。我之前曾听说过'页面锁定争用'，但似乎很少在提及和反对GUID的论据中提及。你说得对，我在转换到聚集索引之前想要等待的想法可能是错误的。 – cbp 2009-05-27 01:59:49

-4

如果这是SQL Server，则通过调用newid（）来生成Guid。这对主键不太合适。为主键使用整数标识列，并使Guid成为代理键（以及行GUID列）。

来源

2009-05-27 01:27:36 cdonner

这就是为什么他要问切换到newsequentialid（）来代替。 – 2009-05-27 01:32:02

您可能会考虑使用comb guids，而不是newsequentialid。

cast(
    cast(NewID() as binary(10)) + 
    cast(GetDate() as binary(6)) 
as uniqueidentifier)

梳GUID是与当前日期时间的非随机性沿着纯粹随机的GUID的组合，以使得梳的GUID连续世代彼此接近并且通常以升序排列。 Comb guid与newsequentialid相比有很多优点，包括它们不是黑盒子的事实，您可以在默认约束之外使用此公式，并且可以在SQL Server之外使用此公式。

来源

2009-05-27 01:40:02 yfeldblum

我想过他们，但我想我宁愿选择'支持'功能。我想我可以在理论上将表从newid（）切换到COMBs，但没有问题，因为数据类型是相同的。 – cbp 2009-05-27 02:01:21

谢谢你，yfeldblum！您对COMB GUID的简单而简洁的解释确实帮助了我。实际上，我正在考虑做与本文相反的内容：由于我试图将SQL Server 2012数据库迁移到Azure，因此我不得不依靠newsequentialid()，并且newsequentialid()函数在那里不受支持。

我能够改变我所有的表PK违约梳理的GUID，语法如下：

ALTER TABLE [dbo].[Company] 
ADD CONSTRAINT [DF__Company__Company_ID__72E6D332] 
    DEFAULT (CONVERT([uniqueidentifier],CONVERT([binary](10),newid(),0)+CONVERT([binary](6),getdate(),0),0)) FOR [CompanyId] 
GO

我SQL2012数据库现在快乐地生活在Azure云。

来源

2014-10-24 18:04:24 andyyee

将newid（）更改为现有表上的newsequentialid（）

回答

相关问题