EF Core页面加载时自动生成Identity相关查询的来源及处理咨询

查询来源 #

这些SQL是ASP.NET Core Identity默认的UserClaimsPrincipalFactory生成的。
使用[Authorize]特性时，身份验证中间件会先从登录Cookie中解析出用户ID，随后调用该工厂类查询数据库，拉取用户基础信息、用户自定义声明、用户关联角色、角色基础信息、角色关联声明共5类数据，用于构建当前请求的ClaimsPrincipal身份对象，这就是你看到的批量查询的来源。

是否可以忽略 #

如果你的系统用户规模小、请求并发量低，这类查询对性能的影响几乎可以忽略。但如果用户量过万、单页面请求频次高，每次请求触发5次数据库查询会带来明显的性能开销，尤其是用户、角色相关表数据量较大时，不建议直接忽略该问题。

优化方案 #

1. 把声明写入Cookie，避免每次查库 #

这是最常用的优化方案：在用户登录时就把所有需要的身份信息（用户基础属性、角色、声明）全部写入Cookie的Claims中，后续请求直接从Cookie解析身份，不需要查询数据库。
配置步骤如下：

• 自定义声明工厂类，继承默认的UserClaimsPrincipalFactory，重写CreateAsync方法，将需要的所有身份信息一次性添加到Claims中
• 注册Identity时替换默认工厂，同时调整安全戳校验间隔降低查库频率：

builder.Services.AddIdentity<IdentityUser, IdentityRole>(opt =>
{
    // 按需调整安全戳校验间隔，权限实时性要求低可以设为1-2小时
    opt.SecurityStampValidationInterval = TimeSpan.FromMinutes(30);
})
// 替换为你自定义的声明工厂
.AddClaimsPrincipalFactory<CustomUserClaimsPrincipalFactory>();

后续业务需要用户信息时，直接从HttpContext.User.Claims中读取即可，不需要再重复查询数据库。

2. 缓存用户身份数据 #

如果不适合在Cookie中存储过多内容，可以将用户的身份相关数据存入内存缓存或分布式缓存（如Redis），设置合理的过期时间，每次请求先查缓存，未命中再查询数据库，可大幅降低数据库请求量。

3. 合并查询减少数据库交互 #

如果确实需要每次请求查库，可以自定义身份验证逻辑，将原来分散的5次单表查询改为多表关联查询，一次性拉取所有需要的身份数据，把数据库交互次数从5次降到1次。

4. 调整安全戳校验策略 #

Identity默认会定期校验安全戳，避免用户权限变更后旧身份还能访问系统。如果你的业务对权限变更的实时性要求不高，可以调大SecurityStampValidationInterval的数值，仅在到达校验周期时才查库更新身份信息，其余时间直接读取Cookie解析身份。

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