mongodb索引键长度上限为1024字节，超限导致createindex()报错“index key pattern too large”；长字段名增加索引体积、降低缓存命中率、加深b-tree层级、增加i/o，且wiredtiger不压缩索引数据；缩写字段名（如usr/addr/ts）、扁平化嵌套路径、避免sparse/partial/ttl等伪规避手段，须在设计阶段约束命名。
字段名过长直接导致索引创建失败或性能下降
MongoDB 索引键（key）长度上限是 1024 字节，这个限制针对的是「索引字段路径的字符串表示」，包括嵌套路径中的所有字段名。比如 {"user.profile.address.street_name": 1}，整个字符串 "user.profile.address.street_name" 就算在内。一旦超过 1024 字节，createIndex() 会直接报错：Index key pattern too large。
这不是理论风险——真实业务中用 user_basic_information_v2_last_updated_timestamp 这类长字段名建复合索引时，三四个字段一拼就超限。
- 字段名每多 1 字节，每个文档在索引 B-tree 节点里就多存 1 字节；索引体积膨胀，内存缓存命中率下降
- 长字段名让索引页更早填满，B-tree 层数变深，查询时磁盘 I/O 次数增加
- WiredTiger 压缩对索引页本身不生效（只压缩文档存储），所以“压缩引擎”无法缓解索引键长度问题
压缩存储引擎（WiredTiger）对索引键无效
很多人误以为启用 WiredTiger 的 block_compressor: "zlib" 或 "snappy" 能压缩短字段名带来的索引膨胀，但事实是：WiredTiger 不压缩索引数据文件（.wti 文件），只压缩集合数据文件（.wt）。索引结构本身以未压缩的 B-tree 形式常驻内存和磁盘。
你可以用 db.collection.stats() 查看 indexCount 和 indexSize，对比长/短字段名集合的 indexSize，差异几乎线性增长——压缩开关开不开，这个值都不变。
- 想靠
storage.wiredTiger.collectionConfig.blockCompressor降低索引内存占用？行不通 -
collMod无法重命名已有字段来“修复”已建索引，必须删索引 + 改字段名 + 重建 - 如果已在生产环境用了长字段名，且索引已接近 1024 字节临界值，
db.currentOp()中看到索引构建卡住，大概率就是键超长触发静默失败
真正有效的字段名瘦身策略
不是所有字段都值得缩写，但高频查询、参与复合索引、嵌套层级深的字段，必须优先处理。缩写原则不是“越短越好”，而是「业务可读 + 团队共识 + 不歧义」。
- 用
usr替代user，addr替代address，ts替代timestamp—— 这些是通用缩写，日志和监控系统也认 - 避免单字母（如
u,a），它在explain("executionStats")输出里根本看不出含义 - 嵌套路径尽量扁平：把
{"profile": {"contact": {"email": 1}}}改成{"profile_contact_email": 1}，既避开嵌套字段名叠加，又方便建单字段索引 - 改字段名前，先用
db.collection.getIndexes()检查哪些索引含该字段；删索引前确认没有应用正依赖_id外的索引名硬编码
稀疏索引不能绕过字段名长度限制
有人想：字段存在率低，那就加 sparse: true 减少索引体积？没用。sparse 只跳过不含该字段的文档，但索引键本身的结构定义（即字段路径字符串）仍完整参与计算，超长照样报错。
同理，partialFilterExpression 也不能缩短索引键长度——过滤条件里的字段名同样计入 1024 字节。
-
db.coll.createIndex({"a_very_long_field_name_that_exceeds_limit": 1}, {sparse: true})→ 依然失败 - TTL 索引、文本索引、地理空间索引，全部受同一长度限制约束
- 唯一能“规避”的方式，是根本不用那个长字段建索引；改用计算字段（如聚合视图）或应用层映射
createIndex() 报错才回头改。
