SQL Server 中唯一标识符 ID 列上的聚集主键

发布于 2024-07-17 01:01:38 字数 108 浏览 8 评论 0原文

如果表上的 ID 列是唯一标识符 (Guid),那么在 ID 列上创建聚集主键是否有意义?

鉴于它们在全球范围内都是独一无二的,那么排序将如何进行?

If your ID column on a table is a unique identifier (Guid), is there any point creating a clustered primary key on the ID column?

Given that they are globally unique, how would the sorting work?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

不弃不离 2024-07-24 01:01:38

GUID 对性能来说非常糟糕,因为它们实际上是随机值(这会“破坏”聚集索引),而且它们对索引来说也很糟糕,因为单个页面/范围上适合的条目较少(SQL Server 术语)。 SQL Server 2005 引入了 newsequentialid() 这有助于解决第一个问题。

GUIDs as they are are terrible for performance since they are effectively random values (this "breaks" clustered index), and they are awful for indexes, since less entries fit on a single page/extent (SQL Server terms). SQL Server 2005 introduces newsequentialid() which helps solving first problem.

淡看悲欢离合 2024-07-24 01:01:38

我强烈建议不要使用集群 Guid 键...由于几年前如此糟糕的设计,我们在 SQL Server 上遇到了很大的性能问题。

另请查看:提高集群索引 GUID 主键的性能

I strongly advise against using clustered Guid key... We had big performance issues on SQL server because of such poor design a few years ago.

Also check out: Improving performance of cluster index GUID primary key

街角迷惘 2024-07-24 01:01:38

将聚集索引放在 guid 列上并不是一个好主意(除非您使用顺序 guid)。

聚集索引决定了记录存储的物理顺序。
这意味着,如果您将聚集索引放在不连续增长的列上,SQL Server 将进行一些工作以确保在插入新记录时记录的物理排序正确。

Putting a clustered index on a guid column is not such a good idea (unless you're making use of sequential guids).

The clustered index determines the physical order of how the records are stored.
This means that, if you put a clustered index on a column that does not sequentially grow, SQL Server will have some work making sure that the records are correctly ordered physically when you insert new records.

小兔几 2024-07-24 01:01:38

拥有排序索引的想法本身就非常好,因为搜索变得非常高效。

然而问题是,如果使用 GUID,则永远不会使用“WHERE GUID = xyz”进行搜索。 所以整个概念都被浪费了。 因此,我建议在最常用作 SARG 的列上建立聚集索引,以提高查询效率。

The idea of having a sorted index is very good in itself as searching then becomes very efficient.

The problem however is that in case of a GUID one never searches with "WHERE GUID = xyz". So the whole concept is wasted. So I would suggest to rather have a clustered index on a column which is used most often as a SARG to increase the query efficiency.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文