优化Mongoid Find查询性能：分片Mongo集合查询问题咨询

看起来你现在遇到的问题是分片集合下通过_id查询时触发了全分片扫描（SHARD_MERGE阶段），导致性能不佳，对吧？结合你的场景——500万+记录、分片键是{user_id: 1, address_id: 1}，我给你几个实用的优化方向：

1. 优先使用分片键字段查询（最推荐） #

你的分片键是复合的user_id + address_id，如果业务场景允许，尽量通过这两个字段组合查询，而不是单独用_id。比如把查询改成：

UserAddress.where(user_id: "目标用户ID", address_id: "目标地址ID").explain

这样mongos可以直接根据分片键计算出数据所在的分片，精准路由到单个分片查询，完全避免跨分片的SHARD_MERGE操作，性能会提升很多。

2. 给_id查询添加路由线索（必须用_id时） #

如果业务上只能通过_id查询，核心问题是mongos不知道这个_id存在哪个分片，只能广播查询到所有分片。解决思路是给mongos提供分片键的线索：

• 方案A：维护反向映射表
  创建一个辅助集合（比如user_address_id_mappings），存储_id到user_id的映射关系。每次插入user_addresses时，同步插入一条映射记录：

  # 插入user_address时同步写映射
  user_address = UserAddress.create(user_id: xxx, address_id: yyy)
  UserAddressIdMapping.create(_id: user_address.id, user_id: xxx)
  

  查询时先从映射表拿到user_id，再结合_id查询：

  mapping = UserAddressIdMapping.find("5ace54343b816c0cdf4b2aa9")
  user_address = UserAddress.where(user_id: mapping.user_id, id: mapping.id).first
  

  这样mongos可以通过user_id精准路由到对应分片，再用_id过滤，避免全分片扫描。

• 方案B：自定义包含分片键信息的_id
  如果还在业务初期或者可以接受数据迁移，把_id改成包含user_id的格式（比如字符串类型的"#{user_id}_#{随机后缀}"）。这样查询_id时，mongos可以解析出user_id，直接路由到对应分片。不过这个方案需要修改已有数据的_id，成本较高，需要谨慎评估。

3. 确保分片节点的单键索引有效性 #

虽然MongoDB默认会给_id创建单键索引，但还是要确认每个分片上的user_addresses集合都存在_id索引。可以在每个分片的mongod实例上执行：

db.user_addresses.getIndexes()

如果没有_id索引，手动创建：

db.user_addresses.createIndex({_id: 1})

这样即使是广播查询，每个分片上的_id查找也能走索引，提升单分片的查询速度。

4. 评估调整分片键（长期优化） #

如果_id查询是高频操作，而当前分片键{user_id:1, address_id:1}不太适配这种查询模式，可以考虑调整分片键。比如改用user_id作为单分片键（前提是user_id的基数足够大，能均匀分布数据）。不过重新分片需要迁移500万+数据， downtime和成本较高，需要结合业务优先级来决定是否执行。

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