开启认证后聚合查询变慢，大概率是权限模型配置不当所致：system.users和system.roles缺索引会触发全表扫描，跨库$lookup导致权限检查翻倍，连接未复用使scram握手积少成多，且auth耗时隐藏于authstats而非executionstats中。
开启认证后聚合查询变慢，**大概率不是认证本身拖慢了查询，而是权限模型配置不当，导致每次查询都触发冗余的权限检查路径或元数据加载**。MongoDB 的 auth 模块在 4.0+ 版本中已高度优化，单次认证开销通常在微秒级；真正造成可观测延迟的，是角色绑定不合理、资源匹配低效、或 system.roles/system.users 集合未建索引。
为什么 system.users 和 system.roles 缺索引会拖慢聚合？
MongoDB 在执行任何操作（包括聚合）前，会校验当前用户对目标集合/数据库是否有对应 action 权限。这个校验过程需要查 system.users（找用户定义）、再递归查 system.roles（展开角色继承链），最后比对资源模式（如 {resource: {db: "orders", collection: "sales"}, actions: ["find"]}）。
若这两个系统集合没有索引，尤其当角色嵌套深、用户数多时，每次聚合都会触发 COLLSCAN —— 这在千万级用户/角色的管理平台中尤为明显。
实操建议：
- 检查
system.users是否有{user: 1, db: 1}唯一索引（默认存在，但自定义部署可能被删） - 为
system.roles显式创建复合索引：db.system.roles.createIndex({"role": 1, "db": 1}) - 避免使用通配符角色（如
root@admin）执行高频聚合；改用最小权限角色，减少角色展开深度
$lookup 跨库聚合时权限检查翻倍的原因
当聚合管道含 $lookup 且指向其他数据库的集合（如从 orders 库查 users 库），MongoDB 会分别检查当前用户在两个库上的权限。若用户角色只在 admin 库定义，而权限语句未显式指定 db 字段，auth 引擎可能 fallback 到全库扫描匹配角色 —— 这个过程无法利用索引加速。
常见错误现象：同一聚合语句，在单库内快（20ms），跨库后飙升到 800ms+，explain("executionStats") 显示 authStats 中 checkTimeMicros 占比超 90%。
实操建议：
- 跨库聚合使用的账号，其角色必须明确绑定到每个涉及的数据库，例如：
db.runCommand({createRole: "readOrdersAndUsers", privileges: [{resource: {db: "orders", collection: ""}, actions: ["find"]}, {resource: {db: "users", collection: "profiles"}, actions: ["find"]}], roles: []}) - 禁止使用
anyResource或clusterAdmin类宽泛角色执行业务聚合 - 用
db.runCommand({connectionStatus: 1})确认当前连接实际生效的角色列表，排除隐式继承干扰
SCRAM-SHA-256 认证握手与连接复用的关系
开启认证后若应用未正确复用连接（比如每次请求新建 MongoClient），SCRAM-SHA-256 握手会重复执行 —— 包含随机 nonce 交换、HMAC 计算、服务端密码验证。虽然单次握手耗时仍低于 1ms，但在 QPS > 500 的场景下，积少成多会导致平均延迟抬升 3–5ms。
更隐蔽的问题是：某些驱动（如早期 pymongo 3.x）在启用 SSL + SCRAM 时，默认禁用连接池复用，导致每次聚合都走完整 TLS + Auth 流程。
实操建议：
- Spring Boot 项目确认
spring.data.mongodb.uri中包含maxPoolSize=100&minPoolSize=10等连接池参数 - Node.js 使用 mongodb driver 时，确保
useUnifiedTopology: true开启（否则可能绕过连接复用逻辑） - 用
db.currentOp({secs_running: {$gt: 0.1}})观察是否存在大量auth类型的长时 operation
最易被忽略的一点：权限检查的耗时不会出现在 executionStats.executionTimeMillis 里，它藏在 authStats 或 server 日志的 accessControl 模块中。不主动查 db.setLogLevel(1, {component: "accessControl"})，就永远看不到真实瓶颈在哪。
