MongoDB的text索引非高性能全文检索方案，数据超10万易超时或漏查；因WiredTiger单线程倒排、无分词缓存、不支持高亮与多字段排序，且$text无法与$sort等聚合阶段共用。
MongoDB 的 text 索引不是高性能全文检索方案，尤其在数据量超过 10 万后，$text 查询极易超时或返回不全——这不是配置问题，是引擎限制。
为什么 text 索引查得慢还容易漏结果
WiredTiger 存储引擎对 text 索引的实现是单线程倒排、无缓存分词、不支持高亮和相关性排序（仅靠 score 粗略排序）。更关键的是：$text 查询无法与 $sort、$facet 或大多数聚合阶段组合使用，一加就退化为 collection scan。
常见错误现象包括：
-
db.articles.find({ $text: { $search: "mongodb 性能" } }).explain("executionStats")中totalDocsExamined接近集合总数 - 搜索含停用词（如“的”“和”）时直接报错
error: text index required - 对中文字段建了
text索引，但搜索仍返回空——因为默认default_language: "english"，中文被整段丢弃
必须改用 text 索引时的最低可用配置
如果业务强约束只能用 MongoDB 原生能力（比如无法引入外部服务），那至少要避开默认陷阱：
- 显式指定中文分词语言：
db.articles.createIndex({ title: "text", content: "text" }, { default_language: "zh", weights: { title: 10, content: 2 } }) - 禁用停用词（否则中文“我”“你”等全被过滤）：
{ default_language: "none", language_override: "language" }，并在文档里手动加language: "zh"字段 - 绝不把
$text放在$and复合条件里——MongoDB 会忽略索引，强制扫描；必须用{ $text: ... , status: "published" }这种“索引字段 + 其他字段”结构 - 查询时必须用
{ $meta: "textScore" }排序，且只允许sort({ score: { $meta: "textScore" } })，其他 sort 字段会失效
真正能落地的替代方案：绕过 $text，用预分词 + 普通索引
把全文检索逻辑下沉到应用层，MongoDB 只负责高效匹配。实操路径如下：
- 写入时用 IKAnalyzer / jieba / mmseg 对
content字段分词，存入新字段keywords: ["mongodb", "性能", "优化", "索引"] - 为
keywords建普通数组索引：db.articles.createIndex({ keywords: 1 }) - 查询改用
$in：db.articles.find({ keywords: { $in: ["mongodb", "性能"] } })，配合$elemMatch控制精度 - 如需权重，可扩展为
{ word: "mongodb", weight: 5 }结构，再建复合索引{ "keywords.word": 1, "keywords.weight": -1 }
这个方案让查询从 O(N) 降为 O(log N)，且完全兼容 $sort、$limit 和聚合管道。
别碰 text 索引的三个临界点
当你的场景出现以下任一情况，立刻放弃原生 $text：
- 集合文档数 > 50 万 ——
text索引构建时间陡增，后台阻塞写入 - 要求搜索结果按时间/热度排序，而非纯相关性 ——
$text不支持多字段 sort - 需要高亮、拼写纠错、同义词扩展 —— WiredTiger 完全不提供这些能力
这时候该上 Elasticsearch 或 Meilisearch，而不是调 weights 参数硬扛。MongoDB 的定位是文档数据库，不是搜索引擎——强行让它干，最后卡在 explain 里看 stage: TEXT 一行行扫，比调参花的时间多十倍。
