小程序云开发的数据库用的是类似 MongoDB 的文档模型，写起来很爽，但数据量一上来，查询慢得让人抓狂。很多新手第一反应是加机器、加缓存，其实八成情况只是少建了索引。
简单说，只要你的查询里用了 where 条件、排序 orderBy、或者联表查询，对应字段就该建索引。比如按 openid 查用户、按 createTime 排时间线、按 category 过滤分类，这些字段没有索引，数据库只能全表扫描，几千条就明显卡，几万条直接超时。
建索引要注意组合索引的顺序。最左匹配原则要记住：如果常用查询是 where category=x AND status=y，那就建 (category, status) 的组合索引，而不是反过来。单字段索引解决不了组合过滤的性能问题。
另一个坑是索引不是越多越好。每多一个索引，写入时就要多维护一份结构，插入和更新会变慢。只给真正用于查询和排序的字段建，避免滥用。可以用云开发控制台自带的慢查询日志，盯着哪些语句在扫全表。
还有一点：模糊查询 like、正则查询基本用不上索引，量大时尽量改成前缀匹配或换搜索方案。如果业务里搜索是重头戏，廷云信息这类团队通常会建议你引入专门的检索服务，而不是硬扛在数据库上。
我们帮一个社区小程序做体检时，发现它的动态流按时间排序却没给 createTime 建索引，五千条数据查询就要三秒多。补上索引后降到几十毫秒，列表滑动立刻跟手。索引是性价比最高的优化，没有之一。
我们帮一个社区小程序做体检时，发现它的动态流按时间排序却没给 createTime 建索引，五千条数据查询就要三秒多。补上索引后降到几十毫秒，列表滑动立刻跟手。索引是性价比最高的优化，没有之一。
下次再听到谁说小程序云开发慢，先去控制台看一眼索引面板，大概率能找到答案。把索引当成上线前必查项，能省掉日后大把救火时间。
把建索引写进上线检查单：凡是 where、orderBy、联表用到的字段，先确认有没有索引。我们习惯在持续集成里加一条慢查询告警，谁的新代码拖慢了接口，第一时间就能收到通知，不至于上线后才被用户骂。