MongoDB中$regex默认不走索引，仅当前缀匹配（^开头且无i标志）时可命中B-tree索引；通配符开头或忽略大小写会导致全表扫描，根本原因在于B-tree索引无法支持无序模式匹配。
正则查询为什么默认不走索引
MongoDB 对 $regex 的索引支持非常有限：只有当正则表达式是「前缀匹配」（即以 ^ 开头、无前置通配符）且不带 i 标志（忽略大小写）时，才可能命中普通 B-tree 索引。一旦出现 ^.*abc、.*abc 或加了 /abc/i，MongoDB 就会放弃索引，直接全表扫描。
根本原因在于 B-tree 索引只支持有序范围查找，而通配符开头的正则无法转换为有效范围；加上 i 会让索引字段值与查询值在二进制层面不一致，破坏索引可比性。
- 常见错误现象：
db.users.find({name: {$regex: "john"}})或db.users.find({name: {$regex: /john/i}})完全不走索引 - 即使字段上有
{name: 1}索引，explain() 显示"stage": "COLLSCAN" - 线上高频触发时，CPU 打满、慢查询堆积、其他请求被拖慢
改用前缀匹配让普通索引生效
把模糊逻辑收束到「已知前缀 + 后续任意」，就能复用已有 B-tree 索引。关键不是改写查询语法，而是约束用户输入或后端拼接方式。
- 允许的写法：
db.users.find({name: {$regex: "^John"}})—— 必须以^开头，且不能带i - 如果业务必须忽略大小写，得建小写归一化字段，比如
name_lower，再建索引{name_lower: 1}，查询时转成db.users.find({name_lower: {$regex: "^john"}}) - 注意：
^John.*和^John效果等价，MongoDB 会自动补.*，但显式写上更清晰 - 不要依赖
$options: "i"，它会让索引失效，哪怕只用于小写字段
通配符索引（Wildcard Index）不是万能解药
从 MongoDB 4.2 起支持通配符索引，但它不解决正则问题，而是为动态字段结构提供索引能力。对 $regex 查询，它依然只加速前缀匹配，且有明显限制：
- 通配符索引如
{"$**": 1}不会提升{$regex: "xxx"}性能，除非配合^前缀 - 它会对所有字段建索引，显著增加内存与写入开销，线上慎用
- 无法控制索引粒度，比如你只想索引
profile.name，但{"profile.$**": 1}仍会索引profile.email、profile.phone等所有子字段 - explain() 中若看到
"stage": "IXSCAN"但"nReturned"极低，说明索引扫了大量无效键值 —— 这是通配符索引典型低效表现
真正可行的替代方案：文本索引 + $text
如果业务本质是「关键词搜索」而非「模式匹配」，$text 查询比 $regex 更高效、更可控，且天然支持大小写和词干处理。
- 先建文本索引：
db.users.createIndex({name: "text"}) - 查询改用：
db.users.find({$text: {$search: "john"}})—— 自动忽略大小写、支持多词、可配权重 - 注意：
$text不支持正则语法，也不能查子串（如 "oh" 不会匹配 "john"），但它适合人名、标题、标签类搜索 - 若需同时支持前缀 + 全文，可双索引并存：
{name: 1}用于^John，{name: "text"}用于$text，由查询条件自动选择
最易被忽略的一点：很多团队花时间调 $regex 的索引，却没意识到业务场景其实不需要正则 —— 比如「搜用户」本应是前缀或全文，而不是「匹配邮箱中含数字的字符串」。先确认真实语义，再选技术路径，比硬刚索引规则更省力。
