ASP.NET Core Identity 主键性能问题答案

【问题标题】：ASP.NET Core Identity Primary key performance concernsASP.NET Core Identity 主键性能问题
【发布时间】：2018-07-04 22:05:20
【问题描述】：

ASP.NET 核心的默认实现使用Guid 作为用户和角色表的主键。

我担心的是，在数据库设计过程中，开发人员经常需要将实体与用户 ID 作为外键链接，例如添加 ModifiedBy 和 CreatedBy 列进行审计，在这种情况下，外键将在执行JOINs 和其他类型的查询时，成为nvarchar(450) 与int 主键相比效率远远不够。

我知道我可以将身份核心配置为使用自定义主键类型，例如 int，但出于安全考虑，我是否应该坚持使用默认配置（我不是安全专家）？

与int 外键相比，字符串外键上的JOINs 不是非常慢（加上主键是nvarchar，这使得情况更糟）？

P.S：我一般不会在 ASP.NET 核心的上下文之外使用代码或 EF

【问题讨论】：

标签： asp.net-core .net-core asp.net-identity entity-framework-core

【解决方案1】：

其实默认的PK类型是string。它只是看起来像Guid。无论如何，PK 本质上是一个索引列，所以它实际上是什么类型是无关紧要的。使用您喜欢的任何类型都没有安全问题，因此如果您更喜欢整数，请使用整数。或者，您实际上也可以使用真正的Guid。在这种情况下，您最终会在数据库中得到一个 uniqueidentifier 列。总而言之，这主要只是您的个人喜好。不过，我确实倾向于使用整数。

【讨论】：

只是为了确保我得到了正确的结果，因此对 nvarchar 索引列的 JOIN 和查询是有效的，并且从长远来看不会对 25k 用户造成任何问题？
是的。这就是索引的全部意义所在。现在，您的数据库的整体大小可能会受到影响，但查询性能应该大致相同。
@sarepta 25K 记录对于 SQL Server 来说不算什么。除非你做的事情完全不合时宜，否则你可以接受这种规模的任何类型的 PK。
@ChrisPratt - 你能否详细说明你的评论 - 这让我大吃一惊！
一个 int 是 4 个字节（32 位），而一个 Guid（或看起来像 Guid 的东西）是 32 个字节（技术上是 36 个字节，因为 .NET 添加了破折号）。简单地说，为 PK 和 FK 使用 Guid 需要更多字节进行编码。对于标准数据库，差异可能很小，但在某些大型应用程序中，这可能是必须考虑的问题。但是，无论哪种方式，列都会被索引，因此查找并不会真正受到值大小的影响（在大多数情况下）。