【发布时间】：2014-06-17 12:14:24
【问题描述】：
我在 MongoDB 中有一个用户集合。 _id 目前是标准的 MongoDB 生成的 ObjectId。我还有一个针对所需“电子邮件”字段的唯一键约束。这似乎是一种浪费。
我有什么理由不应该放弃“电子邮件”字段并将该数据设为 _id 字段？
【问题讨论】：
标签： mongodb uniqueidentifier unique-index
【发布时间】：2014-06-17 12:14:24
【问题描述】：
我已阅读 Neil 的回答，我部分同意（我也对“显着的性能提升”持怀疑态度）。我在您的问题中没有找到的一件事是“您将如何处理这封电子邮件”。你是要搜索它还是它只是保存在那里？之前的答案中没有解决的最重要的事情之一：它会改变吗？
使用您系统的人会更改他们的电子邮件（丢失/不再使用）的情况并不少见。如果您将_id 作为他们的电子邮件，您将无法轻松更改它（您无法在 mongo 中修改_id）。在这种情况下，您将需要复制、删除添加新元素（这不是原子的）。
所以我认为这是不这样做的一大理由。但您需要决定是否允许人们更改电子邮件地址。
【讨论】：
-
这种罕见的用例 - 电子邮件更改 - 可以通过添加带有实际电子邮件的单独文档/行/列来避免，不是吗？您不必复制所有数据 - 您只需添加实际的电子邮件通知即可。
-
@NikolayFominyh 这并不是罕见的情况。而且我非常怀疑添加包含一些信息的新文档而不是将电子邮件作为您的 _id 字段更简单。
-
@SalvadorDali，是的。但是您仍然不必复制所有数据。我只是在谈论它。添加别名需要应用程序中的更多逻辑，但不像看起来那么多。 :)
一般来说，没有真正的原因，事实上，如果您确实使用“电子邮件”作为主键，则可以实现显着的性能提升。
您的大部分查找实际上都在该主键上。即使为不同的字段创建唯一键，MongoDB 也进行了优化，因此“查找”
_id字段索引是轻而易举的事。它一直都在。没有额外的空间用于索引。因此，在您查找主键的地方，除了默认索引之外，不需要拉入任何东西，这自然会节省磁盘空间以及否则会产生的 I/O 成本。
也许唯一真正相关的考虑因素是分片。只有当您的用例更适合“高/低”容量用户的某种不同形式的“分桶”分布时，才会出现这种情况。在这种情况下，需要一些其他形式的主键来促进这一点。
通常占用_id 字段的默认ObjectId 类型非常棒，因为它保持了自然的插入顺序，甚至还可以执行基于范围的查询甚至基于时间的查询（在合理范围内） .因此，在需要自然插入顺序的情况下，它通常是最佳选择，并且具有高度的碰撞安全性。
但是，如果您通常在寻找有效的主键值查找，那么任何用作自然主键的东西都理想地放在集合的_id 字段中，只要它可以合理地保证是唯一的。
【讨论】：