MongoDB处理百万手游用户高并发的主要机制是通过分片（Sharding）、副本集（Replica Sets）和索引优化来实现的。首先，开启分片，将数据分布到多个服务器上，每个分片处理部分数据，高并发请求被分散；其次，副本集提供高可用性和读扩展，主节点写，副节点读；另外，合理设计索引，避免全表扫描，使用连接池管理连接数，结合缓存如Redis减轻数据库压力。性能调优包括调整写关注（Write Concern）和读偏好（Read Preference），监控慢查询并优化。

来源1

对于手游这种高并发场景，MongoDB的分片是关键。我们用range分片或hash分片，根据用户ID或服务器ID分片，一个游戏服可能有几十万用户，分到多个shard，每个shard用3节点副本集，主节点处理写，从节点读。结合业务层负载均衡，QPS轻松破百万。索引上，复合索引覆盖查询字段，避免sort阶段内存溢出。还用mongos路由所有请求，透明分片。

来源2

百万用户高并发，MongoDB靠Replica Set读扩展和Sharding水平扩展。每个mongos前面放HAProxy或Nginx做连接池和限流。写操作用w:1快速确认，读用secondaryPreferred分散压力。数据模型设计很重要，嵌入式文档减少join，预聚合计算如玩家等级用单字段存。监控用mongostat和slow query log，热点数据分库分表。

来源3

手游实时排行榜、背包等高频读写，用MongoDB时先建TTL索引自动清理过期数据；分片键选高基数如userId+timestamp，避免热点；启动时配置chunk大小64MB，预 splitter均衡数据。客户端用10连接池，事务用snapshot isolation。高峰期结合Kafka异步写，MongoDB做最终一致存储。测试QPS达50w+，延迟<50ms。

来源4

性能机制：WiredTiger存储引擎支持压缩和文档级锁，替换MMAPv1提升并发；Covered Query用索引全覆盖不回表；Aggregation Pipeline高效聚合如玩家在线统计。运维上，Rolling Upgrade零停机扩展节点。手游场景，session集合分片，玩家数据按服ID分片，战斗日志用capped collection。

来源5

我们项目百万DAU手游，MongoDB集群10 shard x 3 replica，mongos 5台。优化点：schema设计扁平化，数组不超过100元素；bulk write批量插入道具变更；findAndModify原子更新HP/MP。读用tag sets指定最近副本。结合业务缓存，命中率90%，数据库只剩10%流量。报警规则TPS>80%加节点。

来源6

高并发瓶颈常在锁和磁盘IO，MongoDB用global lock转为collection lock，WT引擎更细粒度。手游登录峰值，用change streams监听数据变更推给前端。分片迁移后台自动，balancer均衡chunk。代码示例：db.runCommand({split: "users", middle: {userId: 500000}})

来源7

Q: MongoDB分片键怎么选？
A: 手游选均匀分布字段如ObjectId或复合(userId, shardKey)，避开低基数如gender。

Q: 如何监控MongoDB高并发性能？
A: 用mongostat实时看QPS/锁%，mongotop IO，profiler抓慢SQL，Ops Manager或Cloud Manager图表。

Q: 副本集读扩展有延迟吗？
A: 有oplog延迟，通常秒级，用slaveOk或ReadPreference.SECONDARY_NEAREST。

Q: 手游大表怎么优化？
A: 垂直分表如player_base和player_equip分开，水平分服ID分片，用covered index加速查询。