不能直接对大文本字段用$regex模糊查询，因其无索引时全表扫描、无法利用b-tree索引前缀加速，且大型文本难满足^开头前提；应建text索引并注意中文分词、索引唯一性及$text查询约束。
为什么不能直接对大文本字段用 $regex 做模糊查询
因为 $regex 在无索引支持时会全表扫描，哪怕只查 10 万条文档，只要字段值平均超 2KB，响应就可能从毫秒级拖到秒级。更糟的是，$regex 无法利用普通 B-tree 索引做前缀加速（除非写成 ^开头 形式），而大型文本字段几乎不可能满足这个前提。
必须先建 text 索引，且避免 $** 通配符滥用
对大型文本字段做高效搜索，唯一可行路径是使用 MongoDB 的文本索引机制。但不是随便建一个就行：
- 用
db.collection.createIndex({content: "text"})显式指定字段，比{"$**": "text"}更可控——后者会把所有字符串字段都纳入索引，包括你根本不会搜的log_message或raw_html，徒增索引体积和写入延迟 - 如果字段含中文，
text索引默认分词失效，必须配合预处理：用jieba或hanlp提前切词，存成数组字段（如content_tokens），再对这个数组建普通索引{content_tokens: 1} - 单个集合只能有一个
text索引，建错就得先dropIndex()，别手抖覆盖掉已在线使用的索引
$text 查询的三个关键约束条件
$text 看似简单，但漏掉任意一条都会导致查询退化为全表扫描：
- 必须在有
text索引的集合上执行，且查询语句里只能出现$text、$search、$language、$caseSensitive这几个键；混进$gt或$in就会绕过文本索引 -
$search值不能是变量拼接的动态字符串——比如"\"" + userInput + "\""，MongoDB 会拒绝解析带运行时拼接的引号，应改用严格格式："\"精确短语\" -排除词" - 想按相关性排序，必须显式投影
{$meta: "textScore"}并用.sort({score: {$meta: "textScore"}})，否则$text只返回结果，不附带评分
大文本字段的替代方案：别让数据库干全文引擎的活
当文档量超过 500 万或单字段平均长度超 10KB，text 索引的构建耗时和内存占用会明显上升。这时候该考虑边界：
- 用
mongot（MongoDB Atlas Search）替代原生text索引，它基于 Lucene，支持同义词、拼音、高亮，且不共享主节点资源 - 导出文本字段到
Elasticsearch或Meilisearch，用_id做关联，查完再回 MongoDB 拉其余字段——虽然多一次网络调用，但响应稳定在 50ms 内 - 如果只是“包含某关键词”这种简单需求，且能接受少量误报，用
$expr+$strLenCP配合应用层缓存关键词位置，比全文索引更轻量
真正卡住性能的，往往不是查询写法本身，而是没意识到：MongoDB 的 text 索引本质是个轻量级分词器，不是 Elasticsearch。越早承认这点，越少在生产环境凌晨三点重启 mongod。
