guid 的性能与 sql 中的字符串相比如何
对于大型 SQL Server 2008 数据表上的主键，我可以选择使用 guid 或大约相同大小的字符串。
从性能角度来看，在进行连接、选择等操作时，guid（16 字节）与大约 16 个字符的字符串相比如何。SQL 是否更擅长处理 guid，因为它们在内部表示为数字？
For primary keys on a large SQL Server 2008 data table, I have the choice of using guids or a string of about the same size.
Performance-wise, how does a guid (16 bytes) compare to a string of about 16 chars, when doing joins, selects, etc. Is SQL better at handling guids because internally they are represented as a number?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
理想情况下，对您问题的简短回答是，两者都不使用。
如果您可以使用 int/bigint 密钥（正如我在回答您的 中所建议的那样）相关问题），你应该这样做。
除非您需要非破坏性地合并存储在多个 SQL Server 实例上的数据集副本的功能，否则使用 GUID 主键会增加索引维护的相当大的开销。 这篇文章对该问题进行了合理的讨论。
如果您生成的序列是一致排序的，则字符串 PK 应该具有较少的开销 - 即新值总是添加在表的“末尾”。
The short answer to your question is, ideally, to use neither.
If you can use an int/bigint key (as I suggested in my answer to your related question), you should.
Unless you need the functionality to non-destructively merge copies of this dataset stored on more than one SQL Server instance, using a GUID primary key adds a considerable overhead in index maintenance. This article has a reasonable discussion of the issue.
A string PK should have less overhead if the sequence you generate is consistently ordered - i.e. new values are always added at the "end" of the table.