本文背景

抽奖助手小程序开发采用云开发模式，通过本次总结可以看到，当云开发小程序数据达到一定级别（比如单个集合数据超过10万）会不会存在瓶颈，这个问题我只抛出来，不做结论

首先说明一下，小程序本身没有问题，在用户少的情况下，没有太多历史数据积累，小程序非常流畅，本文讨论的具体场景是当存在较多历史数据，小程序日活UV相对较大，比如5000左右，单个抽奖参与人数在1500，每天投放100个抽奖奖项，这种量级

集合添加索引已经不能解决问题了，小程序过多依赖云函数，但是云函数请求已经超出20秒的上限

f

f

问题表现

f

当云函数由于超时报错时，首页抽奖记录不能展示，首页就只有很空的两个广告

通过下图左边面板我们不难看到，云函数调用失败的频率太高了，云函数失败有两种原因

1、云函数整体调用时间超时

2、云函数内部执行某种数据库查询超时

调用失败，代表首页抽奖列表页不能正常展示，抽奖的入口就没有了，问题非常严重，由于目前云函数使用大量的联表查询，联表查询在数据量过大的时候，必然会存在这种问题，所以说只能从逻辑上优化

首页的逻辑就是根据当前用户查询抽奖列表，并根据用户已参与的抽奖，进行状态标记，从逻辑上很简单，我举个例子

当前未开奖，也就是可抽奖有以下几条记录

001、002、003、004、005、006、007、008、009

当前用户已参与的抽奖有

001、002、003

那么需要在展示的时候，把001、002、003的状态标记为已抽奖

通过两次查询，便可以完成，具体代码在云函数queryLottery中，由于代码是开源的，对该优化代码感兴趣的可以打开看看，具体的对比效果如下图所示

f

之前联表查询20秒都不够，现在只需要100毫秒，效果非常明显的，提高了200倍

f

本文内容

抽奖助手小程序包含了三个核心模块

（1）首页，主要展示，中奖记录以及奖项记录

（2）详情页，顾名思义，就是单个奖项详情，主要展示详情信息，比如参与人数

（3）我的，主要统计我参与抽奖的一个统计信息

截止目前，我已完成上面模块中(1)(3)的优化，具体优化的过程，我会在本文详细的阐述下，对于模块(2)的优化，我会在后面补充或者单独开一篇新的文章用来记录

本文总结

本文首先描述了，当前小程序遇到的瓶颈，然后给出了具体的优化方案，通过这次优化将云函数提高了200倍，20秒降到100毫秒，在这里通过实践可以给出一个结论：

在数据量大的情况下，为充分利用索引的作用，不建议做联表查询，可以将联表分开拆成多个单一集合查询，然后通过逻辑来实现联表的作用