MongoDB索引的collation规则必须创建时显式指定，因它是索引结构的固化部分，无法动态追加或修改；查询若未显式传入匹配的collation，则无法命中对应索引，导致全表扫描。
直接回答：MongoDB 3.4+ 支持在 createIndex 中通过 collation 选项指定不区分大小写的排序规则，但必须显式声明 locale 和 caseLevel: false（默认），且索引字段类型需为字符串或支持 collation 的类型（如字符串数组）。
为什么 collation 必须显式传入才能生效
MongoDB 不会自动为已有索引“追加” collation；索引的 collation 是创建时固化的一部分。即使查询用了 collation，若索引没配对应规则，就无法命中——查询会退化为全表扫描或使用非 collation 索引再内存过滤。
-
db.users.createIndex({ name: 1 })创建的索引不带 collation，后续find({ name: "Alice" }).collation({ locale: "en", strength: 2 })无法利用它 - 必须重新建索引：
db.users.createIndex({ name: 1 }, { collation: { locale: "en", strength: 2 } }) -
strength: 2表示忽略大小写和重音（即 case-insensitive + accent-insensitive），strength: 1还会忽略宽度（如全角/半角），但多数场景用2足够
strength: 2 和 caseFirst: "upper" 的实际影响
strength 控制比较粒度，caseFirst 决定大小写相同时的排序倾向（仅当 strength ≥ 3 时生效）。对纯不区分大小写查询，caseFirst 几乎无影响。
- 用
strength: 2："apple"、"Apple"、"APPLE" 视为完全等价，索引中只存一个逻辑值 - 误设
strength: 1可能导致意外匹配（如 "Ａｐｐｌｅ" 全角字符也被视为等价），但中文环境少见，一般无需启用 -
caseFirst: "upper"在strength: 2下不生效——因为大小写已被忽略，不存在“谁先”的问题
复合索引 + collation 的常见陷阱
collation 只作用于索引中**明确声明了 collation 的字段**，其他字段仍按默认二进制排序。混合使用易导致索引失效。
- 错误写法：
db.users.createIndex({ name: 1, status: 1 }, { collation: { locale: "en", strength: 2 } })—— 此时status字段也强制套用该 collation，但status是数字或字符串枚举，用strength: 2可能破坏语义（比如"active"和"ACTIVE"被当成相同值） - 正确做法：只为字符串字段单独指定 collation，用
collation对象精确控制字段级行为：db.users.createIndex({ name: 1, status: 1 }, { collation: { locale: "en", strength: 2 } })仍不推荐；应拆成两个索引，或确保所有参与 collation 的字段都确实是字符串且需要统一规则 - 更安全的复合索引：若只需
name不区分大小写，status严格匹配，建两个索引：{ name: 1 }带 collation，{ status: 1, name: 1 }不带 collation（除非 status 也是字符串且需忽略大小写）
验证索引是否被正确使用
不能只看 explain() 里有没有 indexName，关键要看 executionStats.executionStages.stage 是否为 IXSCAN，且 collation 字段与查询一致。
- 执行：
db.users.find({ name: "alice" }).collation({ locale: "en", strength: 2 }).explain("executionStats") - 检查返回中的
executionStats.executionStages.indexName是否为你创建的 collation 索引名 - 确认
executionStats.executionStages.collation与查询中传入的完全一致（字段顺序、键名、值都需匹配） - 如果看到
COLLSCAN或IXSCAN但collation字段为空，说明索引未命中——大概率是 collation 配置不一致（比如 locale 写成了"en_US"而索引用的是"en"）
collation 索引一旦创建，locale 和 strength 就不可修改，只能删掉重建。线上集合数据量大时，createIndex 会阻塞写入（除非加 { background: true }），务必在低峰期操作。最常被忽略的是：查询时忘记传 collation 对象——索引建了，但查的时候没用，等于白建。
