MongoDB 并非每次读取索引统计信息都直接扫描底层数据结构，而是依赖内存中的统计缓存和后台刷新任务来维护索引使用情况。错误码 2590 的本质，是索引统计信息刷新任务尚未完成或刷新请求发生重叠时，新的统计读取操作无法获得一致数据，于是命令直接返回失败。这个问题在高频执行 indexStats 聚合阶段、集合上建了大量索引、分片集群由 mongos 统一汇聚统计信息的场景中尤其突出。
一、故障码 2590 的触发条件与底层机制
MongoDB 为每个索引维护访问计数、命中次数、块读取量等运行时指标。这些指标并不会随着每一次查询同步写入磁盘，而是先记录在内存结构中，由后台任务按照固定节奏刷新。当客户端通过聚合管道中的 indexStats 阶段读取这些数据时，数据库需要把内存中的统计结果整理成可返回的格式。如果此时后台刷新任务正在写入或清理旧数据，读取请求就可能撞上刷新窗口，从而返回 code 2590。
该错误的常见触发条件包括：应用或监控系统每几秒调用一次 db.collection.aggregate([{ $indexStats: {} }])；多个微服务同时访问同一个 mongos；集合中索引数量过多导致单次刷新需要遍历大量元数据；磁盘 IO 延迟升高使刷新任务迟迟不能完成；长事务或慢查询占用资源，间接拖慢统计刷新。以上因素叠加后，错误会从偶发变成持续出现。
下面是一个典型的错误返回示例，codeName 通常为 IndexStatsRefresh 或 IndexStatsRefreshTimeout：
// 聚合执行失败时的返回结构
{
ok: 0,
errmsg: "IndexStatsRefresh timed out",
code: 2590,
codeName: "IndexStatsRefresh"
}
二、从日志与运行状态定位 2590
定位问题的第一步是查看 mongod 日志。日志中如果出现 index statistics refresh timed out、IndexStatsRefresh failed 或大量 code 2590，说明刷新任务持续时间已经超过了命令等待窗口。可以按时间范围过滤日志，确认错误是否与业务高峰、大量聚合查询或磁盘 IO 尖峰同时出现。如果日志量较大，可以先关闭非关键实例的冗余日志，保留 mongod 主节点和 mongos 的关键记录。
接下来可以通过 db.currentOp 观察正在运行的 indexStats 请求。执行下面的脚本可以列出当前所有包含 indexStats 阶段的活动命令，并查看它们已经运行了多长时间：
db.adminCommand({
currentOp: 1,
$or: [
{ "command.aggregate": { $exists: true } },
{ "command.indexStats": { $exists: true } }
],
active: true
}).inprog.forEach(function(op) {
if (op.command && op.command.pipeline && Array.isArray(op.command.pipeline)) {
const hasIndexStats = op.command.pipeline.some(function(stage) {
return stage.$indexStats !== undefined;
});
if (hasIndexStats) {
printjson({
opid: op.opid,
client: op.client,
secs_running: op.secs_running,
command: op.command
});
}
}
});
如果发现同一个 client 在短时间内发起了大量 indexStats 请求，基本可以确认是应用侧或监控侧的调用频率过高。还可以使用 db.serverStatus().metrics.commands.indexStats 查看累计执行次数和失败次数，再结合 db.collection.stats().indexSizes 评估索引体量。定位结果会影响后续的短期缓解和长期优化策略。
三、临时缓解与长期优化方案
临时缓解的核心是给应用层增加指数退避重试机制。因为 2590 通常表示刷新窗口冲突，稍等几百毫秒后重新执行往往就能成功。下面是一个 mongosh 中可用的重试函数，遇到 code 2590 时会等待逐渐延长的时间后重试：
function runIndexStatsWithRetry(collName, maxAttempts, baseDelayMs) {
let attempt = 0;
let delay = baseDelayMs;
while (attempt !== maxAttempts) {
try {
return db.getCollection(collName).aggregate([{ $indexStats: {} }]).toArray();
} catch (e) {
if (e.code !== 2590) {
throw e;
}
if (attempt === maxAttempts - 1) {
throw e;
}
sleep(delay);
delay *= 2;
}
attempt++;
}
}
比简单重试更有效的是降低统计查询频率。很多运维平台每 5 秒拉取一次索引统计，实际上索引使用情况并不需要如此高的实时性。可以改成每 60 秒采集一次，或者在应用内缓存上一次成功返回的结果，当查询失败时使用旧数据作为兜底。这样可以明显减少刷新任务与读取请求的碰撞概率。
长期优化必须回到索引设计本身。集合上索引越多，刷新统计时需要扫描的元数据就越多，单个刷新任务耗时越长。可以通过 db.collection.getIndexes() 检查索引列表，确认是否有长期未使用或重复前缀的索引。对于确认不再需要的索引，使用 dropIndex 及时清理。索引数量下降后，不仅 2590 错误会减少，写入性能通常也会提升。
四、分片集群与版本差异下的特殊处理
在分片集群中，如果客户端通过 mongos 执行 indexStats，mongos 需要把请求分发到相关分片并汇总结果。只要其中一个分片返回 2590，整个命令就可能失败。此时不应只在 mongos 侧频繁重试，而应检查各个分片主节点的日志和 currentOp，确认是哪一个分片拖慢了刷新。监控采集时，也可以优先连接到每个分片的主节点分别获取统计信息，而不是全部通过 mongos 汇聚。
不同 MongoDB 版本对索引统计缓存的实现存在差异，部分补丁版本会修复刷新任务调度或超时判断中的缺陷。如果 2590 错误在业务压力不大时仍频繁出现，建议先在测试环境复现相同负载，并对比当前版本与最新补丁版本的表现。升级前要完整备份配置和索引定义，升级后观察 db.serverStatus().metrics.commands.indexStats 的失败次数是否明显下降。只有在确认版本修复有效后再在生产环境推广，这样可以避免盲目升级带来新的兼容性问题。
MongoDB 2590indexStats索引统计信息刷新修改时间：2026-08-27 22:46:24