我正在使用ASP MVC和MSSQL构建一个云Web应用程序。客户端将共享相同的数据库。我还没有决定我的主键是什么类型。我应该使用 GUID 还是 Bigint？对于Bigint，我担心可扩展性。使用 GUID，我害怕性能。这里的最佳实践是什么？像stackoverflow这样的大型云网站使用什么作为主键？请给我一些启示。
谢谢
雷纳尔迪
我会使用Guids。在处理备份和还原时，您不希望使用顺序 ID。
我会使用 INT，因为性能优于任何其他数据类型，您可以拥有最好的数据类型作为主键。您可以使用 INT 获取超过 20 亿条记录，如果您在一个表中需要超过 20 亿个主键，您应该考虑表分区。但是，使用 GUID 或 BIGINT 无论如何都会降低性能，即使您的表中只有几千条记录。INT 是 4 字节数据类型，GUID 是 16 字节数据类型，因此您可以说需要 INT x 4 内存来存储 GUID 列并加上性能损失。这是 GUID 与 Int 的详细比较marc_s非常详细的答案
两者都有其优点和缺点。真正的问题不是使用哪种数据类型，而是"将以何种方式使用数据"？
例如，如果您打算以数百万次读取的方式使用数据，并且您需要按插入顺序对数据进行"排序"，并且以插入的方式对数据进行"排序"是有意义的，那么也许 IDENTITY INT 列就可以了。 真的不需要 BIGINT， 你甚至可以用 -20 亿来播种你的 INT 列，并且其中可能有 40 亿条记录，我怀疑你会到达那里。如果你想"分片"或扩展你的表，你不会想要使用 int 或 bigint。特别是当您使用 SQL Azure 时，这使得横向扩展变得简单，然后您希望更多地转向使用 GUID 的方向。
当然，使用 GUID 时，它不会按插入顺序在表中"排序"，但如果计划横向扩展，甚至用于联接其他数据库中的表，则使用它绝对有意义。
如果您要进行大量批量插入，例如每批 10,000 行加，那么像 INT 这样的东西会更适合，因为它可以避免页面拆分，或者将其保持在最低限度。但是，如果批量插入发生在安静时间，则这不是问题。
同样，SQL Server 索引非常出色，如果您可以为表获得适当的索引，则无需不使用它们中的任何一个。
索引是另一壶鱼，但由于它不是问题的一部分，我不会在这里尝试回答它，但如果我是你，我会花一点时间来理解太多/太少或错误的索引对桌子的影响。
实际上，问题的答案并不像 GUID 或 INT/BIGINT 那么简单，而是对应用程序、其用法以及如何以及何时使用表的整体视图和理解。只有这样，您才能做出最适合您餐桌的决定。
我希望这有所帮助。