文档数据库服务设计规范 文档设计规范 集合中的 key尽量不要使用任何 “”(下划线)以外的特殊字符。 尽量将同样类型的文档存放在一个集合中,将不同类型的文档分散在不同的集合中;相同类型的文档能够大幅度提高索引利用率,如果文档混杂存放则可能会出现查询经常需要全表扫描的情况。 尽可能不要使用 id ,如:向 id 中写入自定义内容。 文档数据库服务的表与InnoDB相似,都是索引组织表,数据内容跟在主键后,而 id 是文档数据库服务中的默认主键,一旦 id 的值为非自增,当数据量达到一定程度之后,每一次写入都可能导致主键的二叉树大幅度调整,这将是一个代价极大的写入,所以写入就会随着数据量的增大而下降,所以一定不要在 id 中写入自定义的内容。 尽量不要让数组字段成为查询条件。 如果字段较大,应尽量压缩存放。 不要存放太长的字符串,如果这个字段为查询条件,那么确保该字段的值不超过1KB;MongoDB的索引仅支持1K以内的字段,如果你存入的数据长度超过1K,那么它将无法被索引。 尽量存放统一了大小写后的数据 。 如果评估单集合数据量较大,可以将一个大表拆分为多个小表,然后将每一个小表存放在独立的库中或者sharding分表。 索引设计规范 文档数据库服务的组合索引使用策略与 MySQL 一致,遵循”最左原则”。 索引名称长度不要超过 128 字符。 应尽量综合评估查询场景,通过评估尽可能的将单列索引并入组合索引以降低所以数量,结合1,2点。 优先使用覆盖索引。 创建组合索引的时候,应评估索引中包含的字段,尽量将数据基数大(唯一值多的数据)的字段放在组合索引的前面。 文档数据库服务支持 TTL 索引,该索引能够按你的需要自动删除XXX秒之前的数据并会尽量选择在业务低峰期执行删除操作;看业务是否需要这一类型索引。 在数据量较大的时候,文档数据库服务索引的创建是一个缓慢的过程,所以应当在上线前或数据量变得很大前尽量评估,按需创建会用到的索引。