答题活动小程序复盘（一个数据库查询语句把应用拖垮了） - WXOPEN Club

答题活动复盘（一个数据库查询语句把应用拖垮了）

我昨天很自豪的写了下面的文章，今天就啪啪打脸了

具体过程是这样的

今天下午7点我还悠闲的坐在星巴克的长椅上品着嘴里的卡布奇诺，微信的客服消息就开始陆续有用户反馈小程序无法使用，无法答题了

我就寻思不可能呀

昨天10万+好好的，今天用户还没昨天多

赶紧打开小程序，问题可以复现，这问题就严重了，我以迅雷不及掩耳之势就溜回了宿舍，打开电脑一堆超时报错，这种超时报错有

1）云函数的超时

2）数据库查询的超时；

对于云函数的超时，我首先想到的就是把云函数的超时时间从默认的3秒设置为20秒

对数据库查询的报错，我核对了下是否有漏加索引，排查了下，并没有说因为索引未设置而出现查询变慢，因为我本人做活动已经有很多经验（教训），所以在活动对外前一天，会有计划的把一些常用的查询，设置索引

所以对于这种查询突然超时的问题，我也是没有思路

当时的请求，每秒的并发也就几十个

此时只能甩锅给腾讯云，开始发工单，联系技术，腾讯方面也迅速拉了群，群策群力，大概有2个小时，问题得到解决，也给出了结论

开始拉群排查问题

从接近9点开始拉群（其实从7点多发现问题，自己排查30分钟，发现问题无法解决，8点左右工单已经发起了）

9点50分，问题得以解决，事故持续了大概3个小时

虽然最后通过扩容把问题解决了，但是导致问题的原因，在腾讯云技术复盘后，也给出了具体的诱因，就是我的逻辑中有一个全表的查询，导致把数据库负载提高了

这个查询是解决我们的一个业务需求加的，具体的需求是

活动方要求活动如果大于50万就不允许用户再参与了，所以每次用户答题之前我都查询了目前的用户数量，就是这个查询的全表扫描，导致了本次问题的出现

结论

1）逻辑中尽量不要出现全表扫描的操作；

2）尽量减少联表，哪怕冗余一些数据；

图片占位

最后还要感谢群里出谋划策的大佬们