如何优化MongoDB Schema以移除_id字段的无用默认索引？

嘿，针对你提出的优化需求，我结合你的集合结构、查询模式和分片计划，整理了一套贴合业务的实操方案，咱们一步步来：

一、先划重点：_id默认索引的删除限制 #

MongoDB天生会给每个集合的_id字段建一个唯一索引，但这个索引不是想删就能删的，规则很明确：

• 非分片集合：根本删不了！MongoDB强制要求_id全局唯一，全靠这个索引兜底呢。
• 分片集合：
  • 如果你的分片键包含_id：可以删掉这个默认索引，因为分片键的复合索引已经能保证_id的全局唯一性（每个分片内的_id唯一，加上分片键的路由逻辑，全局自然唯一）。
  • 如果分片键不包含_id：别想删了，MongoDB得靠它保证跨分片的_id不重复。

二、结合你的业务场景的两种方案 #

你的查询只有两种模式，而且已经建了两个非常贴合的索引，所以分片键的选择是核心——直接决定能不能删掉_id的默认索引：

方案A：硬刚要删_id索引？选包含_id的分片键 #

如果你铁了心要删掉_id的默认索引，就得把_id塞进分片键里，推荐用{id_to: 1, _id: 1}作为分片键：

• 好处：满足你删除_id默认索引的需求，减少一点索引维护开销。
• 小缺点：分片键带了个_id，但你的查询根本不用它，不过因为前缀是id_to，大部分查询还是能精准路由到对应分片，影响不大。

操作步骤：

1. 先给数据库开分片权限（假设你的分片集群已经搭好了）

sh.enableSharding("你的数据库名")

2. 创建分片键对应的索引
   MongoDB要求分片键必须有对应的索引，所以先建这个复合索引：

db.like.createIndex({id_to:1, _id:1})

3. 给集合分片
   执行分片命令：

sh.shardCollection("你的数据库名.like", {id_to:1, _id:1})

4. 删掉_id的默认索引
   分片完成后，就可以动手删了：

db.like.dropIndex({_id:1})

方案B：更贴合业务的分片键（放弃删_id索引） #

从你的查询模式来看，id_to是所有查询的核心条件，更合理的分片键是{id_to:1}或者{id_to:1, date:-1}——这样所有查询都能精准路由到对应分片，性能最优，但这种情况没法删_id的默认索引：

• 好处：分片键完全贴合业务查询，路由效率拉满，还能降低热点分片的概率（只要id_to的基数足够大）。
• 小妥协：必须保留_id的默认索引，但这个索引的维护开销极低，几乎不会影响性能，完全可以接受。

操作步骤：

1. 给数据库开分片权限

sh.enableSharding("你的数据库名")

2. 复用已有索引当分片键索引
   如果你选{id_to:1}当分片键，你现有的两个索引都以id_to:1为前缀，MongoDB会自动复用，不用额外建索引；如果选{id_to:1, date:-1}，你已经建了这个索引，直接用就行。

3. 给集合分片

# 选{id_to:1}当分片键
sh.shardCollection("你的数据库名.like", {id_to:1})

# 或者选{id_to:1, date:-1}当分片键
sh.shardCollection("你的数据库名.like", {id_to:1, date:-1})

补充说明：

这种情况下，_id的默认索引真的删不掉，但它占的空间和维护成本都很低，没必要纠结这个点，毕竟业务性能更重要。

三、额外的小建议 #

• 你的索引设计已经很到位了：两个查询分别对应两个已有的索引，完美匹配，不用再瞎建索引浪费资源。
• 如果集合数据量很大，分片前建议先做预分片，避免大规模数据迁移拖垮集群性能。
• 关于那个唯一索引{id_to:1, id_from:1}：分片后只要分片键包含id_to，同一个id_to的文档都会落在同一个分片里，这个唯一索引就能保证全局的唯一性，完全没问题。

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