用$regex/i查询慢且无法走普通索引，因其实质是全表扫描；需建collation索引并查询时显式指定相同collation才能高效实现大小写不敏感匹配。
直接用 $regex 加 i 选项最简单，但性能差、无法走普通索引；真要兼顾性能和大小写不敏感，必须用 collation 创建带排序规则的索引，并在查询时显式指定相同 collation，否则索引压根不会被使用。
为什么 $regex /i 查询慢且不能用普通索引
正则表达式匹配（如 {"name": {"$regex": "^john$", "$options": "i"}}）本质是全表扫描：MongoDB 无法利用字段上的标准 B-tree 索引做前缀或等值查找，因为 $regex 的执行逻辑绕过了索引的有序结构。即使字段有索引，该查询也基本等于没建。
- 每次查询都触发字符串逐字符比对，CPU 开销大
- 索引中存储的是原始字节值，
$regex不会自动映射到大小写归一化的索引项 - 除非正则以锚点
^开头且无通配符，否则连「前缀索引」都用不上
创建 collation 索引的正确写法（Python / PyMongo）
索引必须明确声明 collation，且 locale 和 strength 要匹配实际需求。常见错误是只设 locale 却忽略 strength，导致大小写仍被区分。
-
strength: 1（Primary）：只比较字母基础形，忽略大小写、重音、变音 —— 这才是真正的「大小写不敏感」 -
strength: 2（Secondary）：区分重音但忽略大小写（如cafe和café视为不同） - 必须用
create_index显式创建，不能靠查询自动触发
collection.create_index(
[("name", 1)],
collation={"locale": "en", "strength": 1}
)
注意：locale 值不是随便填的字符串，必须是 MongoDB 支持的 ICU 区域 ID（如 "en", "zh", "fr"），不支持 "en_US" 这类带下划线的格式（部分旧版本会静默失败）。
查询时必须传相同的 collation 才能命中索引
这是最容易漏掉的关键点：索引建了，但查询不带 collation，MongoDB 默认用 "simple" 二进制排序规则，完全不走你刚建的索引。
- 正确写法（PyMongo）：
collection.find({"name": "John"}).collation({"locale": "en", "strength": 1}) - 错误写法：
collection.find({"name": "John"})—— 看似一样，但底层排序规则不同，索引失效 - 聚合操作同理：
collection.aggregate([...]).collation({...})
可以用 explain() 验证是否用了索引：find(...).collation(...).explain()["executionStats"]["executionStages"]["stage"] 应为 IXSCAN，而非 COLLSCAN。
collation 索引的限制与替代场景
collation 索引不是万能的，它只对字符串字段的等值、范围、排序类操作生效，且要求查询条件和索引定义严格对齐。
- 复合索引中，只有前缀字段是字符串且带 collation 时，该部分才受排序规则影响；后续数字/日期字段不受影响
- 不能用于
$text索引，$text自带语言处理，但不支持自定义strength - 如果业务需要同时支持「大小写敏感」和「不敏感」两种查询，得建两个索引（一个带 collation，一个不带），空间成本翻倍
真正难处理的是模糊搜索（比如查 "jo" 能匹配 "John"）—— collation 索引对此无效，此时只能回归 $regex 或引入全文索引 + $text，但后者对拼写容错能力有限。
