云开发的云数据库本质上是文档型数据库，底层基于MongoDB。小数据量时怎么查都快，但一旦集合里的文档超过几万条，没有索引支撑的查询就会明显卡顿，云函数响应时间从几十毫秒飙升到数秒。索引优化是云数据库性能调优中最立竿见影的手段，这篇文章围绕单字段索引、复合索引以及常见的索引失效场景展开，帮你把查询性能真正提上来。
一、索引的基本原理与单字段索引
数据库索引的原理和书的目录很像。没有目录时，你要找某一章内容只能一页页翻，对应到数据库就是全集合扫描；有了目录，直接定位到页码，对应的就是索引检索。云数据库为每个集合默认在_id字段上建立了唯一索引，所以按_id查询永远是快的，这也是doc(id).get()这种查询性能稳定的原因。
单字段索引是最简单的索引形式，针对某一个字段建立排序结构。在云开发控制台中进入对应集合，点击索引管理，添加索引并选择字段名即可。举个例子，如果你的订单集合经常需要按用户查询：
// 在集合上为 openid 字段建立单字段索引后
db.collection('orders')
.where({
openid: 'oXXXX_user_openid'
})
.get()没有索引时，这个查询要遍历集合中所有文档逐个比对openid字段；建立了单字段索引后，数据库通过B树结构直接定位到匹配的文档，数据量越大差距越明显。实测在十万条文档的集合上，未加索引的查询平均耗时800毫秒以上，加上索引后降到10毫秒以内。
需要注意两点：第一，索引不是免费的，每个索引都会占用存储空间，并在写入时带来额外维护开销，写入频繁的集合不要无节制地建索引；第二，唯一索引可以用来做数据去重约束，比如防止同一用户重复提交，插入重复值会直接报错，这比在业务代码里先查再插更可靠。
二、复合索引与字段顺序的最左匹配原则
当查询条件涉及多个字段时，单字段索引就不够用了。比如查询某个用户一段时间内的订单，条件同时包含openid和createTime，即使两个字段各自有单字段索引，数据库通常也只能利用其中一个，另一个字段只能在索引命中的结果集里逐条过滤，效率依然不高。这时候需要复合索引。
复合索引是在多个字段上联合建立的索引，字段顺序非常关键。云数据库遵循最左匹配原则：查询条件必须从索引的第一个字段开始连续命中，索引才能被使用。假设建立了复合索引openid + createTime，那么它的命中情况如下：
where({openid, createTime})：完全命中，走索引where({openid})：命中前缀，可以走索引where({createTime})：无法命中，索引失效，全集合扫描
在控制台添加复合索引时，按查询频率最高的字段在前、范围查询字段在后的原则排列。等值查询字段放在前面，范围查询字段放在后面，这样能最大限度利用索引的排序特性。看一个实际例子：
// 复合索引：openid(正序) + createTime(倒序)
// 查询某用户最近的20条订单，性能最佳
db.collection('orders')
.where({
openid: 'oXXXX_user_openid',
createTime: _.gt(1700000000000)
})
.orderBy('createTime', 'desc')
.limit(20)
.get()这个查询因为orderBy的字段正好是复合索引的第二个字段，且方向一致，排序也能直接利用索引完成，省掉了额外的内存排序步骤。如果查询模式多变，可以针对不同查询组合建立多个复合索引，但同样要权衡写入开销，一般一个集合控制在5个索引以内比较合理。
三、常见的索引失效场景排查
建了索引不等于一定生效，很多写法会让索引悄悄失效，这是实际项目中最容易踩的坑。下面几个场景需要重点检查。
第一，对索引字段使用函数或表达式。比如用_.expr或聚合操作对字段做运算后再比较，索引字段经过了函数包装，数据库无法直接利用索引。正确的做法是把计算前置到写入时，比如增加一个dateStr冗余字段存日期字符串，查询时直接等值匹配这个字段。
第二，模糊查询的通配符位置。云数据库的模糊匹配基于正则，如果正则以^开头锚定前缀，索引仍然可用；如果是中间匹配或后缀匹配，索引直接失效。也就是说/^张/可以走索引，而/张/和/张$/都不能。
// 前缀匹配，可利用 name 字段上的索引
db.collection('users').where({
name: db.RegExp({ regexp: '^张', options: 'i' })
}).get()
// 中间匹配，索引失效，数据量大时会超时
db.collection('users').where({
name: db.RegExp({ regexp: '张', options: 'i' })
}).get()第三，隐式类型不匹配。字段存储的是数字类型，查询时传了字符串，或者反过来，索引会失效。云数据库对类型是严格区分的，建议写入时就统一数据类型，时间戳统一用数字或统一用日期对象，不要混用。
第四，不等于和范围过大的条件。_.neq、_.nin这类否定条件对索引不友好，命中范围过大的范围查询（比如查全表90%的数据）优化器可能直接放弃索引选择全扫。这类需求应考虑调整数据结构或改用分页方案。
四、如何验证索引是否生效
怀疑索引失效时，可以用索引分析功能验证。在云开发控制台的索引管理中，部分环境提供索引分析入口，能查看各索引的命中情况；也可以在云函数中通过统计接口对比查询耗时来侧面验证：同一段查询代码，分别建索引前后各跑一次，耗时差异通常是数十倍级别。
另外要养成习惯，凡是where条件里的字段，都问一句它有没有对应索引支撑；凡是新建的查询需求上线前，都在测试环境用真实量级的数据压测一次。云数据库单次查询默认超时时间有限，索引优化不到位往往直接表现为云函数偶发超时，这类问题在开发环境小数据量下完全暴露不出来。
总结一下：优先按高频查询建立复合索引并遵循最左匹配原则，等值条件在前范围条件在后，避开函数包装、中缀模糊匹配和类型不一致这几类失效场景，配合控制台的索引管理工具持续观察。把这几条落实到位，云数据库在百万级文档量下依然能保持毫秒级查询响应。