必须使用/^abc/形式正则并建升序索引，配合explain验证ixscan；推荐$gt/$lt范围查询或4.2+的$startswith；大小写敏感需统一collation或小写归一化。
要在MongoDB中让形如“以abc开头”的字符串查询真正走索引、避免全表扫描和CPU飙升，必须严格满足B-tree索引对正则前缀匹配的硬性约束条件。
确认查询模式是否符合索引可命中条件
先检查你的$regex查询是否写成/^abc/形式——必须带^锚点且不能含i标志；若写成/abc/、/abc$/、/.abc/i或/.*abc/，MongoDB将直接跳过所有B-tree索引，强制执行COLLSCAN。
用explain("executionStats")验证：如果winningPlan.stage是IXSCAN但totalKeysExamined远大于totalDocsExamined，说明索引被部分使用但效率极低；如果stage是COLLSCAN，说明索引完全未生效。
这一步不可跳过。很多团队在加完索引后没验证执行计划，误以为已优化成功。
为前缀字段单独建立升序B-tree索引
对目标字段（如name）执行db.collection.createIndex({name: 1})。
不要用降序（-1），除非你后续明确需要按字典逆序范围扫描；升序索引天然适配/^abc/类前缀查找，B-tree能快速定位到第一个key ≥ "abc"的位置，然后顺序读取所有以"abc"开头的键。
【name字段必须是字符串类型，且不能为null或空字符串；若存在大量null值，该索引选择性会骤降】
重构查询语句并强制使用索引
方法一：用$regex + ^锚点（最常用）
db.users.find({name: {$regex: "^Alice"}})
方法二：用$gt/$lt模拟前缀（更高效，推荐）
db.users.find({name: {$gte: "Alice", $lt: "Alicf"}})
注意：$lt边界必须是前缀字符串的字典后继，即把末尾字符ASCII码+1；若前缀是"Alice"，则"Alicf"正确，"Alicez"错误——后者会漏掉"Alicf"到"Alicez"之间的合法值。
方法三：用startsWith操作符（MongoDB 4.2+）
db.users.find({name: {$startsWith: "Alice"}})
该语法语义清晰，且自动转换为最优索引访问路径，无需手算$lt边界。
处理大小写不敏感场景
第一步：在创建索引时指定collation
db.users.createIndex({name: 1}, {collation: {locale: "en", strength: 2}})
第二步：查询时必须显式带上相同collation
db.users.find({name: {$regex: "^alice"}}, {collation: {locale: "en", strength: 2}})
⚠️ 若只建了collation索引但查询不带collation参数，MongoDB将完全忽略该索引——这是最常踩的坑。
第三步：确保所有写入数据已统一小写归一化（可选但强烈建议）
在应用层入库前将name.toLowerCase()，再配合普通{name: 1}索引和/^alice/查询，彻底规避collation开销。
验证索引真实生效效果
① 执行带explain的查询：
db.users.explain("executionStats").find({name: {$regex: "^Alice"}})
② 检查返回结果中的executionStats字段：
— totalDocsExamined应显著小于集合总文档数
— nReturned应与实际匹配文档数一致
— winningPlan.stage必须为IXSCAN，且indexName与你创建的索引名完全一致
③ 对比未建索引时的same query耗时：若从1200ms降至8ms，说明索引设计与查询协同正确。
这一步完成后，前缀模糊匹配即可稳定命中B-tree索引。
