云开发的数据库查询慢这个问题，我踩过不止一次。第一次是在一个电商小程序项目里，商品列表加载要3秒多，用户疯狂吐槽。我一开始以为是网络问题，换了CDN、加了缓存，效果都不明显。最后才发现，根本原因是没建索引。
云开发的数据库是基于MongoDB的，查询逻辑和传统SQL数据库类似。当集合里的文档数量超过几千条时，全表扫描的代价就很高了。特别是带where条件、排序、联表查询的场景，没有索引基本就是灾难。我那个项目，商品集合有8000多条记录，查询时走了全表扫描，不慢才怪。
怎么判断要不要加索引？我现在的做法是：打开云开发控制台，看慢查询日志。响应时间超过1秒的查询都要重点关注。把查询条件里的字段列出来，常用的where字段、orderBy字段、联表字段都要建索引。一个查询可能涉及多个字段，可以建复合索引。
给那个商品集合加了索引后，查询速度从3秒降到50毫秒，提升了60倍。用户反馈立刻好了很多，转化率也跟着上去了。这个经历让我深刻认识到：数据库优化不是可选项，是必选项。
但建索引也有讲究。索引不是越多越好，每个索引都会占用存储空间，写入时还要维护索引结构。我曾经给一个集合建了十几个索引，结果写入速度变得很慢，存储空间也暴涨。后来优化到5个核心索引，性能反而更好了。
我的建议是：先分析查询模式，把高频查询的字段组合建索引，低频查询可以暂时不加。可以用explain分析查询计划，看有没有走索引。廷云信息做数据库优化时，会先跑一遍全量查询分析，再决定索引方案，这个做法我很认同。
还要注意索引的使用限制。云开发对单条记录大小、索引数量都有限制，超了会报错。建议定期清理过期数据，或者做数据归档，控制集合大小在合理范围内。我现在的项目，超过90天的订单数据会自动归档到历史集合，主集合只保留活跃数据。
除了索引，查询写法也影响性能。避免在where里用正则表达式，尽量用精确匹配。联表查询的数据量要控制，大数据量联表建议分步处理。这些细节做好了，云开发的性能完全可以支撑中等规模的应用。
最后分享一个监控技巧。我在云函数里加了查询耗时日志，超过100毫秒的查询会打警告日志，每天汇总发邮件。这样能快速发现新出现的慢查询，及时优化。性能优化最怕一阵风，建议把优化排进常规迭代，而不是等用户投诉才动。