MongoDB分片集群在管理大规模数据时，经常需要通过创建索引来加速查询。然而不少工程师在给已分片的集合建立索引时，会遇到一个特定的异常提示，错误码为2760。这个故障码的核心含义是：你所尝试创建的索引违反了分片集合关于分片键的强制规则。具体而言，MongoDB要求分片集合上的唯一索引必须包含分片键作为前缀，否则集群无法保证跨分片的数据唯一性，因而直接拒绝该操作。理解这一限制，是排查2760错误并设计合理索引方案的前提。
2760错误的触发原理与分片路由机制
在MongoDB分片架构中，数据按照分片键被分散到不同的分片上。每一个分片只负责一部分数据块，而mongos路由节点根据分片键将请求转发到对应分片。当我们在分片集合上创建唯一索引时，如果索引字段不包含分片键，那么不同分片上可能出现相同的索引键值，而各分片之间无法互相感知对方是否已存在该值，这就破坏了唯一性约束的全局有效性。为避免这种数据不一致，MongoDB在创建索引阶段就通过2760错误进行拦截。
从底层实现来看，分片集合的元数据由config服务器统一管理。当客户端向mongos发送createIndex命令，mongos会先检查集合是否为分片集合，以及索引定义是否含有分片键。如果索引声明了unique:true但未包含全部分片键字段，则直接返回2760。即便不是唯一索引，某些涉及分布式的查询优化也依赖分片键前缀，因此官方建议所有索引尽量以分片键开头。这种设计虽然带来了限制，却保障了分布式环境下的数据正确性。
我们可以通过一个简单例子观察该机制。假设集合按字段tenantId分片，此时若想给email字段建唯一索引就会报错。正确做法是将索引改为{ tenantId: 1, email: 1 }，这样在单一租户内邮箱唯一，且路由层能利用前缀定位。以下命令会触发2760：
// 假设集合已按 tenantId 分片
// 以下操作将抛出 2760 错误
db.users.createIndex(
{ email: 1 },
{ unique: true }
);
常见错误场景与对应的索引改造方案
实际生产中，2760错误最常出现在多租户系统迁移到分片集群的过程中。开发团队原本在单机MongoDB上为orderNo建立了全局唯一索引，迁移时选择userId作为分片键，结果建索引失败。这是因为全局唯一的订单号并不包含userId前缀。面对这种场景，有两种改造思路：一是将索引改为复合唯一索引{ userId: 1, orderNo: 1 }，代价是订单号仅在单个用户下唯一，若业务要求全平台唯一则不可行；二是放弃数据库层唯一约束，在应用层生成带userId前缀的订单号，再用非唯一索引查询。
另一个典型场景是使用哈希分片键。哈希分片会将分片键散列后分布，此时如果创建范围查询索引，也必须包含原分片键字段。有些团队误以为哈希分片键不需要出现在索引中，结果同样碰到2760。正确的做法是显式把哈希分片键作为索引首字段，即使它是被哈希过的，索引定义中仍写原字段名。下列代码展示了兼容哈希分片的复合索引创建方式：
// 使用 userId 的哈希作为分片键
sh.shardCollection('mydb.orders', { userId: 'hashed' });
// 创建包含分片键前缀的复合索引，避免 2760
db.orders.createIndex(
{ userId: 1, createdAt: -1 }
);
对于非唯一索引，虽然MongoDB不会强制要求分片键前缀，但缺少前缀会导致查询必须广播到所有分片，性能极差。因此从运维角度，即便不报2760，也应主动把高频查询字段与分片键组合。我们可借助explain计划观察是否出现SCATTER_GATHER，若有则说明索引未带分片键，需要调整。
预防2760的集群设计规范与运维建议
要在项目初期规避2760错误，最关键的是在选定分片键之前梳理所有唯一性约束。如果业务存在全局唯一字段且无法拼接分片键，应考虑将该全局字段本身作为分片键，或采用范围分片配合Zone来隔离。例如物流系统以regionCode分片，运单号本身含region前缀，那么运单号唯一索引自然包含分片键逻辑。这种前期建模能省去后期索引重构的停机成本。
运维侧建议把索引创建纳入变更评审，任何分片集合的createIndex脚本都先用getShardDistribution确认分片键，再检查索引字段。可以写一个小工具扫描待执行索引，若含unique且不含分片键则自动阻断。此外，MongoDB的滚动索引创建（rolling index build）虽能降低锁影响，但同样受2760限制，不可绕过。以下示例展示如何用shell检查分片键：
// 查看集合分片键
config = db.getSiblingDB('config');
shardKey = config.collections.findOne(
{ _id: 'mydb.users' }
).key;
printjson(shardKey);
// 人工比对：新建索引是否包含 shardKey 中的字段
// 若不含且 unique 为 true，则预判会报 2760
最后需要提醒，部分旧版本MongoDB对2760的报错信息不够清晰，仅提示“cannot create unique index over hashed field”等，容易误导。遇到此类情况应升级到较新稳定版，并查阅对应版本文档。建立规范的索引评审流程和分片键评审机制，才能让系统在面对业务变更时依然保持稳定，不再被2760中断发布窗口。