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?
相关问题
- sql execution latency when assign to a variable
- What is the best way to cache a table from a (SQL)
- php PDO::FETCH_ASSOC doesnt detect select after ba
- Bulk update SQL Server C#
- SQL to Parse a Key-Value String
相关文章
- Entity Framework 4.3.1 failing to create (/open) a
- Code for inserting data into SQL Server database u
- SQL Server 2008 Change Data Capture, who made the
- Delete Every Alternate Row in SQL
- Linux based PHP install connecting to MsSQL Server
- SQL Azure Reset autoincrement
- How do we alias a Sql Server instance name used in
- Is recursion good in SQL Server?
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.