MongoDB集合设置Collation strength=2是否存在性能隐患？最佳实践是什么？

1. 集合级设置 strength=2 的 collation 会增加查询负载吗？ #

会，确实会带来一定的性能开销。因为 strength=2 的规则会忽略大小写和重音，MongoDB 在做字符串比较、排序或者使用索引时，都需要先对字符串做归一化处理（比如统一转成小写后再比对）：

• 如果依赖索引加速，必须创建匹配该 collation 的索引才能生效，不然会触发全表扫描，开销陡增；
• 就算有对应索引，索引的存储空间也会比默认大小写敏感的索引更大，因为要存储归一化后的键值。

2. MongoDB 默认不设大小写不敏感是因为性能考量吗？ #

主要原因是性能，但还有其他关键因素：

• 性能优先：默认的二进制大小写敏感比较是最快的字符串比对方式，不需要额外处理，能保证基础查询的最高效率，符合绝大多数场景的默认需求；
• 通用性：不同语言的大小写、重音处理逻辑差异很大（比如土耳其语的 I/i 规则和英语完全不同），默认用特定 locale 的 collation 会限制数据库的通用性，二进制比较是最中立的选择；
• 向后兼容：MongoDB 早期版本没有 collation 功能，保持默认大小写敏感能保证老版本升级后的兼容性。

3. 最佳实践是保持默认大小写敏感，仅按需给特定字段设 collation 吗？ #

没错，这是更合理的方案：

• 避免全局性能损耗：只有确实需要大小写不敏感查询的字段才配置对应规则，其他字段保持默认的高效二进制比对；
• 适配不同需求：不同字段可能有不同的比对要求（比如用户名需要大小写不敏感，而验证码必须严格区分大小写），字段级或查询级的 collation 能精准适配；
• 优化索引：只为需要的字段创建带 collation 的索引，减少不必要的存储空间和维护成本。

修正后的集合创建代码示例 #

你提供的代码有格式错误，正确的集合级 collation 配置应该把参数放在 collation 对象中：

db.createCollection('myColl', {
  collation: {
    locale: 'en',
    strength: 2
  }
});

另外补充：如果只是个别查询需要大小写不敏感，也可以在查询时临时指定 collation，无需修改集合或索引的默认配置：

db.myColl.find({ username: 'John' }).collation({ locale: 'en', strength: 2 });

内容的提问来源于stack exchange，提问作者Jose