$in查询不走索引主因是类型不匹配、数组过大（超500项易退化）、未覆盖查询字段导致回表，或聚合中误用$expr内$in；需严格保证值类型一致、控制数组长度、避免$expr封装，并通过explain("executionstats")核验totaldocsexamined与nreturned比值。
$in 查询不走索引，通常不是“不支持”，而是条件没对上 —— 索引存在、字段匹配、但执行计划里 totalDocsExamined 还是等于集合总文档数，说明确实没用上。
为什么 $in 查询看起来走了索引，实际却全表扫描
常见错觉：建了单字段索引 db.collection.createIndex({ status: 1 })，然后执行 db.collection.find({ status: { $in: ['active', 'pending'] } })，explain() 显示用了索引，但 totalDocsExamined 高得离谱。
根本原因往往有这几个：
- 索引字段类型和查询值类型不一致（比如索引建在字符串字段上，但传入的是数字
['1', '2']vs[1, 2]）； - 查询数组长度过大（超过几百项），MongoDB 内部会退化为“索引跳跃式查找 + 合并”，但某些版本或场景下触发优化阈值，直接放弃索引路径；
- 查询同时含排序或投影（
.sort()/.project()），而索引未覆盖全部字段，导致不得不回表读取完整文档，最终被优化器判定“不如直接 collection scan”； - 集合极小（ 扫描内存页。
$in 中数组长度超过多少会明显影响索引效果
没有硬性上限，但实测中几个关键拐点值得注意：
- ≤ 50 项：绝大多数情况稳定走索引，响应时间线性增长；
- 100–300 项：开始出现波动，尤其当字段基数低（如只有 3 种
status值）、重复值多时，索引选择率下降，nReturned和totalDocsExamined差距拉大； - > 500 项：部分 MongoDB 版本（如 4.4 之前）会拒绝使用索引，改用 collection scan；5.0+ 虽支持，但
executionStats里常看到多个IXSCAN子节点合并，CPU 和锁竞争上升； - 极端情况（如传入 5000+ ID）：驱动层可能报
errmsg: "BSON object size limit exceeded"或触发 TCP 分片，根本到不了查询引擎。
验证方式：用 explain("executionStats") 查看 executionStages 下是否有多个 IXSCAN，以及 totalKeysExamined 是否接近数组长度 × 索引平均扇出（而非远大于它）。
索引字段数据类型不匹配导致 $in 失效
这是最隐蔽也最常被忽略的问题。MongoDB 的索引严格区分类型，"1"（字符串）和 1（整数）在 B-tree 中是完全不同的 key。
典型失效场景：
- 数据库里
user_id是NumberLong，但应用传入的是字符串数组：{ user_id: { $in: ["123", "456"] } }→ 即使有{ user_id: 1 }索引，也完全不命中； - 日期字段建了
{ created_at: 1 }，但查询传的是字符串 ISO 格式：{ created_at: { $in: ["2025-01-01", "2025-01-02"] } }→ 类型不匹配，索引失效； - 使用 Mongoose 时，Schema 定义为
String，但前端传了数字，或反之；Mongoose 默认不做强制类型转换，find()仍按原始类型查。
检查方法：用 db.collection.findOne() 看真实存储类型，再比对查询语句中字面量的 BSON 类型（可用 typeof 或 BSON.ObjectId() 判断）。
聚合管道中 $in 在 $expr 里永远不走索引
如果你在 aggregate 的 $match 阶段写了 { $expr: { $in: ["$field", [val1, val2]] } }，那这个 $in 就是聚合操作符，不是查询操作符 —— 它不支持任何索引。
MongoDB 官方明确限制：只有 $eq、$lt、$lte、$gt、$gte 这五个聚合比较操作符能在 $expr 中利用索引。
替代方案只有两个：
- 把
$in拆成多个$or+$eq：{ $match: { $expr: { $or: [{ $eq: ["$field", val1] }, { $eq: ["$field", val2] }] } } }； - 完全避开
$expr，改用普通查询语法：{ $match: { field: { $in: [val1, val2] } } }—— 这个才真正走索引。
最后提醒一句：索引是否生效，不能只看 explain() 输出里有没有 IXSCAN，更要看 totalDocsExamined 和 nReturned 的比值。如果前者是后者的上百倍，说明索引只是“被用了”，但没真正解决问题 —— 很可能该建复合索引，而不是继续堆数组长度或调类型。
