SQL Server主键类型选型：Guid与Int孰优？当前最佳实践咨询

这是个非常实际的问题——主键类型的选择确实得结合业务场景和技术约束来权衡，我来帮你梳理下SQL Server里常见的主键方案，以及GUID的现状：

1. 自增整数（INT/BIGINT）：最主流的选择 #

• 核心优势：
  • 性能拉满：占用空间极小（4/8字节），索引维护成本低，排序、查询速度都非常快
  • 业务友好度高：就像你提到的Course/1这种URL形式，不管是用户还是开发者都能直观理解，完全不需要额外维护唯一列
• 局限性：
  • 分布式场景容易踩坑：如果是多节点数据库同步，自增ID很容易出现冲突，得提前规划好步长或者用分段ID
  • 存在数据泄露风险：如果业务逻辑依赖ID，恶意用户可能通过遍历ID（比如Course/2、Course/3）爬取数据

2. GUID（UNIQUEIDENTIFIER）：依然是分布式场景的靠谱选择 #

• 现在用GUID还明智吗？：得看你的业务需求——如果是分布式系统、多数据库实例同步、或者需要离线生成ID的场景，GUID依然是很合适的方案。而且SQL Server现在有优化版的NEWSEQUENTIALID()，它生成的GUID是有序的，解决了传统NEWID()生成无序GUID导致的索引碎片问题，性能比旧版GUID提升了不少。
• 关于URL场景的顾虑怎么解决？：
  你说的没错，原生GUID直接放URL里确实太冗长（比如Course/3F2504E0-4F89-11D3-9A0C-0305E82C3301），这里有两种实用的解决办法：
  • 新增一个短唯一标识列：比如用VARCHAR存储随机字符串，或者直接用自增ID，专门用于对外暴露的URL，主键依然用GUID。这种方式只需要给这个列加个UNIQUE CONSTRAINT或者唯一索引就行，工作量其实不大，还能兼顾内部主键的分布式需求和外部URL的友好性。
  • 缩短GUID的字符串格式：把GUID转换成Base64或者Base32格式，能缩短到20个字符左右，虽然不如自增ID短，但比原生GUID友好很多（比如Course/3F2504E04F8911D39A0C0305E82C3301）

3. 复合主键：仅适合特殊场景 #

• 一般只用于多对多关系的中间表（比如CourseStudent表用CourseID + StudentID作为主键），不推荐作为业务表的主键，因为维护和查询都比较麻烦。

总结建议 #

• 如果你的系统是单数据库实例、没有分布式需求，优先选BIGINT自增主键，完全满足URL友好、性能优异的需求；
• 如果是分布式系统、需要离线生成ID，用NEWSEQUENTIALID()生成的GUID作为主键，再根据业务需求选择是否新增短唯一列用于对外暴露；
• 别为了赶时髦用GUID，得结合实际场景权衡利弊。

内容的提问来源于stack exchange，提问作者chobo2