很多人在用NoSQL数据库时会疑惑：它不像传统的关系型数据库那样有固定的表结构，那还能不能建索引？答案是：能，而且很常见。
索引不是关系型数据库的专利
虽然NoSQL数据库种类多，比如文档型（如MongoDB）、键值型（如Redis）、列族型（如Cassandra）、图数据库（如Neo4j），但大多数都支持某种形式的索引。只是实现方式和使用场景跟MySQL这类数据库不太一样。
MongoDB 的索引很灵活
以MongoDB为例，它是文档数据库，数据存成类似JSON的格式。如果你经常按用户手机号查信息，完全可以给 phone 字段加个索引：
db.users.createIndex({"phone": 1})加完之后，查询速度明显提升，特别是数据量上百万的时候，没索引可能要几秒，有索引可能几十毫秒就搞定。
并不是所有NoSQL都支持复杂索引
像Redis这种内存型键值库，主要靠 key 直接取值，本身不支持二级索引。如果你想通过用户的邮箱找对应的ID，就得自己设计结构，比如用一个额外的key来映射邮箱到ID。
Cassandra 的索引比较特别
Cassandra支持创建二级索引，但用起来得小心。比如你在一个非主键字段上建了索引：
CREATE INDEX ON users (email);看似方便，但在分布式环境下，跨节点查询可能拖慢整体性能。所以实际项目中，更推荐通过合理的表结构设计来替代索引。
索引也有代价
不管哪种数据库，加索引都会带来写入变慢、存储占用增加的问题。NoSQL虽然灵活，但滥用索引照样会让系统变卡。比如你在MongoDB里给十几个字段都建了单独索引，每次插入一条数据就要更新十多个索引树，写入性能自然下降。
就像家里收拾东西，柜子分得越细，找东西越快，但每次买新东西放进去也越麻烦。索引也是这个道理。
实际开发中的建议
先想清楚哪些查询最频繁，再决定要不要建索引。可以看慢查询日志，或者用数据库自带的分析命令，比如MongoDB的 .explain()，看看查询有没有走索引。
另外，复合索引比多个单字段索引更高效。比如你总是一起按城市和年龄查用户，那就建一个 {city: 1, age: 1} 的复合索引，而不是分别给 city 和 age 各建一个。