MongoDB禁止数组字段作分片键，因分片路由要求键值为唯一、稳定、全序可比的标量；含数组则立即报错“cannot shard collection with array value in shard key”，且不可后期修改。
MongoDB 明确禁止将任何包含数组值的字段用作分片键，这不是索引类型问题，也不是 B 树实现缺陷，而是分片路由协议本身的刚性约束：分片键必须提供唯一、稳定、全序可比的标量值，而数组天然破坏这三点。
分片键含数组时会直接报错 "cannot shard collection with array value in shard key"
这个错误在调用 sh.shardCollection() 时立即触发，不等待数据写入或 chunk 拆分。只要集合中任一文档的候选分片键路径（如 "tags" 或 "scores.0"）解析出数组，命令就失败。
- 即使该字段在 99% 文档中是字符串，只要存在一个
{"tags": ["a", "b"]}，整个分片操作就终止 - 错误不是“无法创建索引”，而是“无法建立分片映射关系”——MongoDB 甚至不会尝试建索引
- 后续插入时若让已分片集合的分片键字段从标量变为数组（如先插
{"category": "book"}，再插{"category": ["book", "fiction"]}），会报"cannot change shard key value"
点号路径（"address.city"）能用，但 "tags.0" 不行 —— 关键看实际值类型
点号路径本身被支持，但 MongoDB 在运行时会对每个文档做**值类型校验**：它检查的是该路径最终解析出的内容，而非路径语法是否合法。
-
"address.city"可行，前提是所有文档中address.city都是字符串/数字/ObjectId 等标量 -
"tags.0"不可行，因为tags是数组，tags.0虽指向单个元素，但该路径隐式依赖数组存在；一旦某文档tags缺失或为null，tags.0就是undefined，违反“必须存在或显式为null”的要求 - 更隐蔽的坑：
"metadata.tags"若metadata是子文档但tags字段在部分文档中是数组，在另一些中是字符串，同样失败
多键索引和分片键是两套完全独立的机制
很多人混淆 db.coll.createIndex({"tags": 1})（多键索引）和分片键，以为“能建索引就能当分片键”。事实是：
- 多键索引只影响查询执行计划，比如加速
{"tags": "mongodb"}或{"tags": {"$elemMatch": {...}}} - 分片键参与的是路由层决策：mongos 必须根据键值算出目标 shard，这就要求键值可哈希（哈希分片）或可比较（范围分片）——数组没有全局排序语义，也无法生成确定性哈希
- 你可以同时有
{"tags": 1}多键索引 +{"user_id": "hashed"}分片键，二者无冲突，也互不替代
想按数组内容分布数据？只能靠预处理字段
如果业务确实需要“标签相同的数据尽量落在同一 shard”，唯一合规路径是引入派生字段：
- 新增一个
tags_hash字段，写入前对tags数组做排序 + JSON.stringify + SHA256，存为字符串，再用它做哈希分片键 - 或用业务规则提取主标签（如取第一个、最长的、或按权重选），存为
primary_tag，确保该字段恒为字符串且非空 - 所有写入逻辑必须统一维护这些派生字段，不能依赖应用层“偶尔补全”——分片键字段缺失或类型不一致，会导致后续写入直接被 mongos 拒绝
最易被忽略的一点：分片键一旦设定，其结构（字段名、嵌套路径、是否哈希）就冻结了；改键不是 ALTER TABLE，而是删库重导。设计阶段没压住数组冲动，后期代价远超预估。
