Sequential Guid 主键列应该是聚集索引吗？
使用顺序 guid 的目标是，您可以使用聚集索引，而不会产生高级别碎片，如果它是常规 guid，那么聚集索引中通常会存在这种情况，对吗？
The goal of using a sequential guid is so you can use clustered indexes without the high levels of fragmentation that would normally exist in a clustered index if it was a regular guid, correct?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
首先澄清一下，主键和聚集索引是两个独立且不同的事物，即一个不与另一个耦合（PK 可以是非聚集的，聚集索引可以是非 PK 的）。
鉴于此，我认为您问的是“是否应该将顺序 GUID 用作聚集索引”。这是一个负载问题，但是 Kimberly Tripp 对此进行了讨论，这可能是我见过的最好的讨论者。请注意，本文提到了 PK，但在文章中她提到了如何将考虑因素主要应用于聚集索引选择与 PK。
假设您已经决定使用 GUID 作为集群键（情况可能是也可能不是），那么使用顺序 GUID 很可能是比非顺序 GUID 更好的选择，但是至少有 1 个可能首选非顺序 GUID 的场景（尽管这是一种非常罕见、非常高级的场景，您必须基本了解您的系统和 SQL 服务器，以至于您毫不怀疑应该使用它 - 与存储设备上的热点并将大量写入分散到集群的不同位置）。
First to clarify, a primary key and clustered index are 2 separate and distinct things, i.e. one is not coupled to the other (PKs can be nonclustered, clustered indexes can be non-PKs).
That given, I think you're asking more "Should a Sequential GUID be used as a clustered index". That's a loaded question, but Kimberly Tripp has discussed this probably the best of anyone I've seen. Note that the article referes to a PK, but inside the article she refers to how the consideration applies mostly to a clustered index choice vs. a PK.
Assuming you have already decided to use a GUID as the cluster key (which may or may not be the case), the use of a sequential GUID would most likely be a superior choice to a non-sequential GUID, however there is at least 1 scenario where a non-sequential GUID may be preferred (though a very rare, very advanced scenario where you'd have to basically understand your system and SQL server so well that you have no doubt that this should be used - would have to do with hotspots on your storage device and spreading large-volumes of writes across different locations of the cluster).
是的，你是对的。
Yes, you are correct.