MongoDB 文本索引和正则查询有什么区别？为什么不建议滥用 regex？

简化版

Text Index 面向分词后的文本搜索，regex 是按字符串模式匹配。regex 尤其是前缀不固定的模糊匹配很容易导致大量扫描，搜索需求强时通常应考虑文本索引或专业搜索引擎。

详细版

MongoDB 支持 $text 文本搜索，也支持正则表达式匹配，但两者解决的问题不同。

Text Index 会对文本字段建立文本索引，适合关键词搜索、简单相关性匹配。
regex 是模式匹配，适合格式校验、前缀匹配、少量数据过滤。
/^abc/ 这类左锚定前缀查询可能利用普通索引；/abc/、/.*abc/ 往往难以高效走索引。
Text Index 不等同于 Elasticsearch，复杂分词、排序、聚合、同义词和高亮能力有限。
面试回答要把“能不能用索引”和“搜索体验是否满足业务”分开讲。

完整版教学

一、为什么字符串搜索会分成两类问题

字符串查询看似都是“找包含某个词的记录”，但底层差异很大。查用户名是否以 tom 开头，本质是有序字符串范围查找；查文章里是否出现“事务隔离”，则需要理解词、位置、相关性。regex 更像通用模式匹配工具，Text Index 更像简化版搜索索引。混用这两类问题，会导致设计走偏：用 regex 做全文搜索，数据一大就慢；用 text index 做精确格式匹配，又可能不够直观。

db.articles.createIndex({ title: "text", content: "text" })
db.articles.find({ $text: { $search: "MongoDB index" } })

记忆钩子：regex 是“按字符扫模式”，text index 是“先建词典再按词找”。

二、Text Index 的基本原理

文本索引会把文本字段处理成可检索的词项，并建立从词项到文档的映射。查询 $text 时，数据库不必逐篇文章扫描全文，而是通过词项找到候选文档。这个思路和倒排索引类似：正排是“文档里有什么词”，倒排是“某个词在哪些文档里”。因此 Text Index 适合关键词检索，但它的分词语言、排序能力和高级搜索能力有限，不能直接等价为搜索平台。

文档1: MongoDB index design
文档2: MySQL index design

倒排近似：
MongoDB -> 文档1
MySQL   -> 文档2
index   -> 文档1, 文档2
design  -> 文档1, 文档2

三、regex 为什么容易慢

regex 的性能取决于模式能否转化为有序索引上的范围扫描。/^abc/ 表示字符串以 abc 开头，在普通升序索引里可以近似定位到 [abc, abd) 这个范围。而 /abc/ 表示任意位置包含 abc，B 树索引无法直接从中间字符定位，只能扫描大量候选再匹配。数据量从 1 万增长到 1000 万时，这种差异会被放大很多。

// 可能利用 name 普通索引的前缀查询
db.users.find({ name: /^tom/ })

// 通常代价高，容易扫描大量数据
db.users.find({ name: /tom/ })

四、用数字感受扫描差异

假设 users 有 500 万条，name 上有普通索引。查询 /^alex/ 可能只扫描 2 万个以 alex 开头的索引项；查询 /alex/ 可能要检查大量名字，因为 alex 可能出现在任意位置。即使最后只返回 100 条，慢查询的成本也可能来自“为了找到这 100 条检查了几百万条”。这就是面试官追问 regex 时真正想听到的点：不是 regex 语法本身，而是它和索引有序性的关系。

查询	是否容易用索引	典型风险
`/^abc/`	相对容易	结果范围仍可能很大
`/abc/`	困难	大量扫描后过滤
`$text`	依赖文本索引	搜索能力有限

五、Text Index 的限制和适用边界

Text Index 适合简单站内关键词搜索，比如标题和简介搜索，但它不是完整搜索引擎。复杂中文分词、拼音纠错、同义词、权重调优、高亮、多字段相关性、多条件聚合排序，通常不是 MongoDB Text Index 的强项。如果搜索是核心业务，常见方案是 MongoDB 存主数据，Elasticsearch 或 OpenSearch 承担检索。面试时不能只说“建 text index”，还要补一句“复杂搜索要拆到搜索系统”。

db.articles.find(
  { $text: { $search: "replica set" } },
  { score: { $meta: "textScore" } }
).sort({ score: { $meta: "textScore" } })

六、实战怎么选

如果是精确匹配、枚举字段、前缀搜索，优先普通索引和规范化字段；如果是关键词搜索、内容检索，可以用 Text Index 做轻量方案；如果是任意包含匹配，要警惕 regex 扫描成本。如果业务确实要支持“名称任意位置包含”，可以考虑额外维护 ngram 字段、搜索引擎，或限制数据范围后再 regex。技术选型的关键不是某个语法能不能写，而是数据量、延迟目标和搜索体验是否匹配。

选择路线：
精确/前缀 -> 普通索引
简单关键词 -> Text Index
复杂搜索体验 -> Elasticsearch/OpenSearch
任意 regex -> 控制范围或避免

七、常见误区与追问

误区：MongoDB 支持 regex，所以模糊搜索没问题。 语法支持不代表性能可接受，非前缀 regex 很容易大量扫描。
误区：Text Index 等同 Elasticsearch。 它能做基础文本检索，但复杂分词、相关性和搜索产品能力有限。
误区：返回少就一定快。 如果为了返回 100 条扫描了 500 万条，查询仍然可能很慢。
追问：/^abc/ 为什么比 /abc/ 友好？ 前者能映射到有序索引的前缀范围，后者匹配位置不固定，难以定位。
追问：中文搜索怎么办？ 简单场景可评估 Text Index，复杂中文分词和召回排序通常交给专业搜索引擎。

八、加强记忆

这题抓住“字符模式”和“词项检索”的区别就不会乱。regex 是拿模式去匹配字符串，只有左锚定前缀才比较可能吃到普通索引；Text Index 是先建立词到文档的映射，再按关键词召回。面试时先说机制，再说性能边界，最后给选型：普通索引做精确和前缀，Text Index 做轻量关键词，复杂搜索上专业搜索系统。

简化版

详细版