分片键一旦选定无法修改，错误选择会导致数据倾斜、跨分片查询激增、均衡器失效，架构不可维护；必须停写导出、重建新库并启用合理分片键（如哈希或复合键）才能彻底解决。
分片键选错，sh.shardCollection() 执行完就等于锁死了后续所有扩容效果——数据倾斜、跨分片查询爆炸、均衡器失效，不是“性能差”，而是“架构不可维护”。
为什么改不了分片键？_id 被误设为分片键的硬伤
MongoDB 不允许修改已分片集合的分片键，shardCollection 一旦执行，shard key 就固化在 config.chunks 和 config.collections 中。常见错误包括：
- 直接用
{_id: 1}分片：新写入全打到同一个分片（因 ObjectId 时间戳前缀单调递增） - 用
{created_at: 1}分片：时间序列导致最新数据持续写入单一分片，旧数据冷落 - 用低基数字段如
{status: 1}：只有 “active”/“inactive” 两个值，最多只能分出 2 个 chunk，根本无法扩展
这些情况下，即使加了新分片，balancer 也几乎不迁移数据——因为没 chunk 可拆、没范围可平衡、没哈希空间可分散。
sh.splitAt() 和 sh.moveChunk() 无法挽救设计缺陷
有人试图用预分裂或手动迁移“绕过”问题，但实际效果极有限：
-
sh.splitAt("db.coll", {_id: ObjectId("...")})只对已有 chunk 生效；若整个集合只在一个 chunk（比如刚分片且没写入），该命令直接报错no chunk found -
sh.moveChunk()要求目标分片有足够空间且网络稳定，但若源 chunk 持续被写入（如时间戳键），迁移会反复失败并触发自动回滚 - 手动拆分 + 迁移后，新写入仍按原分片键路由，热点照旧，几天后又回到起点
本质是：分片键决定数据路由逻辑，不是数据分布快照。逻辑错了，操作再勤也白搭。
真正可行的重构路径：停写 → 导出 → 新库重建 → 切流
没有在线重分片方案，必须接受短时停写窗口。关键步骤如下：
- 确认业务可接受停写窗口（通常 30–120 分钟），关闭所有写入客户端或切到只读模式
- 用
mongodump --uri="mongodb://mongos:27017/" --db=db --collection=coll -o ./backup/导出全量数据（注意加--forceTableScan防 chunk 元数据不一致） - 在新数据库启用正确分片策略：
sh.enableSharding("newdb")，再用sh.shardCollection("newdb.coll", {user_id: "hashed"})（哈希防热点）或{region: 1, event_time: -1}（复合键兼顾查询与分布） - 用
mongorestore --uri="mongodb://mongos:27017/" ./backup/导入；导入过程自动按新分片键分发数据 - 验证新库数据一致性（
db.coll.countDocuments()+ 抽样校验）后，切换应用连接字符串指向新库
别跳过验证环节：曾有案例因 dump 时未加 --readPreference=primary，从 secondary 导致部分写入丢失，上线后才发现数据缺口。
下次设计分片键前必须验证的三件事
避免重蹈覆辙，上线前用真实数据模拟压测：
- 跑
db.coll.aggregate([{$group: {_id: "$shard_key_field", count: {$sum: 1}}}, {$sort: {count: -1}}, {$limit: 5}])，确认前 5 名值的占比 ≤ 5%（高基数） - 查
sh.status()中各分片的chunks数量差异是否 ；若某分片 chunk 数超均值 2 倍，说明写入严重倾斜 - 执行典型查询
db.coll.find({shard_key_field: ...}).explain("executionStats")，确认nShards= 1（非广播查询）且executionStages.shards只列一个分片
最常被忽略的是第三点：很多团队只测“能不能分片”，不测“查询是否真落到单分片”。结果上线后发现 90% 查询要扫全部分片，QPS 直接腰斩——这不是扩容，是加拖累。
