问题复盘:
2019.09.27 09:50:00 发现内存出现飙升情况,开发人员对此开始进行了排查
2019.09.27 09:52:00 首先查看相关的请求日志,并没有发现异常日志,且当时并没有大批量调用接口的情况
2019.09.27 10:00:00 因发现启动参数不一致,决定先由运维重新配置并发布一版
2019.09.27 10:12:00 发现内存仍然出现飙升情况
2019.09.27 10:30:00 因查看监控发现该时间点的网络数据请求量很大,让DB运维帮忙看一下数据库查询是否存在问题
2019.09.27 10:35:00 发现有慢查询,语句中出现shopid=0的查询条件(该条件下会查询出大量的解绑数据)
2019.09.27 10:38:00 排查代码逻辑,新加入标签体系的查询中,忽略了查询时需要过滤解绑门店来判断 是否存在服务商设备 标签
2019.09.27 14:50:00 线上PRD环境发布成功后,持续观察,之后再无该问题出现
问题总结:
1、根据一些现象,比如内存和网络的飙升应及时判断出,是出现了大数据量的查询
2、CPU若升高,说明查询频率快,CPU变化不大,则说明出现大数据的查询
3、在日常开发注意查询语句的优化,杜绝数据量查询过多(分批次),或者慢查(索引或者查询方式问题)