SQL Server 性能建议
我一直仅使用数据类型 int 的主键创建数据库表，并且始终具有出色的性能，但需要与可更新订阅者设置合并复制。
这些表使用典型的主键、数据类型 int 和标识增量。设置合并复制时，我必须使用 newsequentialid() 函数将 rowguid 添加到所有表中作为默认值。我注意到 rowguid 已可索引，想知道我是否还需要主键？
可以有2个索引，主键int和rowguid吗？合并复制表的最佳布局是什么？我是否保留 int id 以便于行引用并仅删除索引但保留主键？不知道该走什么路线，谢谢。
I have been creating database tables using only a primary key of the datatype int and I have always had great performance but need to setup merge replication with updatable subscribers.
The tables use a typical primary key, data type int, and identity increment. Setting up merge replication, I have to add the rowguid to all tables with a newsequentialid() function for the default value. I noticed that the rowguid has indexable on and was wondering if I needed the primary key anymore?
Is it okay to have 2 indexes, the primary key int and the rowguid? What is the best layout for a merge replication table? Do I keep the int id for easy row referencing and just remove the index but keep the primary key? Not sure what route to take, Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
请记住，如果删除 int id 列并将其替换为 GUID，则可能需要重新处理大量数据和查询。你真的想做这样的查询吗：
记住，如果你的 id 暴露给任何用户（通常是客户，因为客户表通常没有自然键，因为名称不唯一），他们会发现 guid 令人畏惧做研究。
在现有系统中两者兼具并没有什么问题。在新系统中，您可以计划不使用整数，但如果您尝试在已经使用它们的系统中删除它们，则存在引入错误的巨大风险。
Remember that if you remove the int id column and replace it with a GUID, you may need to rework a good deal of your data and your queries. And do you really want to do queries like:
Remember if your ids are exposed to any users (often in the case of a customer because the customer table often has no natural key since names are not unique), they will find the guid daunting for doing research.
There is nothing wrong in an existing system with having both. In a new system, you could plan to not use the ints, but there is a great risk of introducing bugs if you try to remove them in a system already using them.
用 guid（据我所知）替换整数主键的唯一缺点是 GUID 更大，因此 btree（使用的索引空间）会更大，并且如果您有此表的外键（您也可以需要更改）更多的空间最终可能会被（可能）许多表使用。
The only downside of replacing the integer primary key with the guid (that I know of) is that GUIDs are larger, so the btree (index space used) will be larger and if you have foreign keys to this table (which you'd also need to change) a lot more space may end up being used across (potentially) many tables.