^开头的正则能用索引，因MongoDB仅支持前缀型正则（如^abc）转为范围扫描；.*开头、无锚点或含通配符则无法下推，须全索引或集合扫描。
为什么 ^ 开头的正则能用索引，而 .* 开头的不能？
MongoDB 只对「前缀型」正则表达式使用索引，核心在于它能否将正则转化为范围扫描（range scan）。当模式以 ^ 起始且后续是字面量（如 ^abc），查询引擎可直接定位到索引中 "abc" 开头的所有键；但一旦出现 .*、$ 在开头、或无锚点（如 xyz），就必须全索引扫描甚至全集合扫描。
-
^apple→ 可走索引，等价于范围["apple", "applf") -
apple（无锚点）→ 不走索引，除非字段基数极低且优化器误判 -
.*apple或apple$→ 不走索引，无法下推为前缀范围
注意：即使写了 ^，如果后面跟的是不支持的字符（如 ^a.c 中的 .），索引仍可能失效——MongoDB 当前（v7.0）只对连续字面量前缀生效，不支持通配符混排。
如何创建并验证前缀正则索引？
直接在字段上建普通升序索引即可，MongoDB 会自动在查询时复用它（无需特殊语法）。关键是写对正则、建对字段、查对执行计划。
- 确保查询字段与索引字段完全一致（含嵌套路径，如
tags.name就不能靠tags索引） - 使用
explain("executionStats")检查是否出现"IXSCAN"而非"COLLSCAN" - 示例验证：
db.products.createIndex({ name: 1 })
db.products.find({ name: { $regex: "^iPhone" } }).explain("executionStats")
若输出中 executionStages.stage 是 "IXSCAN"，且 nReturned 远小于 totalDocsExamined，说明索引生效。反之，若 totalDocsExamined === nReturned，基本等于没走索引。
大小写敏感问题导致索引失效的常见陷阱
默认 $regex 区分大小写，但多数业务需要忽略大小写匹配（如搜 "user" 匹配 "User"）。此时若直接加 i 标志：/^user/i，索引将完全失效——因为大小写折叠需逐文档解码，无法在索引层完成。
- 正确做法：建小写冗余字段 + 索引，查询时统一转小写
db.products.updateMany({}, [{ $set: { name_lower: { $toLower: "$name" } } }]) db.products.createIndex({ name_lower: 1 }) db.products.find({ name_lower: { $regex: "^iphone" } }) - 替代方案：用
$text索引（仅适用于完整词干匹配，不支持前缀）或 MongoDB 5.2+ 的collation（但 collation 索引对$regex支持有限，实测 v6.0 仍不触发 IXSCAN）
性能临界点：什么时候该放弃正则，改用其他方案？
前缀正则索引看似高效，但有隐性成本：它本质是范围扫描，当匹配前缀太短（如 ^a）或集合极大时，仍可能扫数万键，延迟陡增。
- 前缀长度 ^x、
^ab）→ 索引选择性差，不如全扫 - 高频前缀查询（如日志
^ERROR）→ 可考虑 TTL 索引 + 归档冷数据 - 需要模糊/近似匹配 → 正则不是解，应换
$text、N-gram 分词（应用层）、或专用搜索引擎（Elasticsearch）
真正高效的前缀查询，往往已经具备结构化潜力：把 "v1.2.3" 拆成 { major: 1, minor: 2, patch: 3 }，用数值范围查比正则快两个数量级。正则索引是补救手段，不是设计起点。
