背景
运营需要签约报表明细做数据分析，前期是通过sql导出全量的数据明细，现在要将线下做到线上。理解为将线下那坨sql挪到代码里，然后在页面给个入口提供查看和下载。
导致也确实是这么做的，将sql原封不动的挪到代码里，然后在service层做分页和查询。在本地和测试环境用postman没有出现接口超时现象，虽然已经意识到接口时长过长，但是潜意识觉着因为sql大，所以时间长是正常的，没想过要改sql,,最主要原因是sql很大，很复杂，怕改错。
结果
结果就是上线后，
1:因为接口请求时间过长，前端直接给了timeout提示，导致列表不显示数据。
2:城市这个查询条件的匹配是通过名字匹配的，参数的来源值和接口返回值的城市名字来源不一致，比如接口返回“吉林市”，参数选择的时候传的是“吉林”就会导致吉林有数据，但是没有查到。
这是第一次上线发现的问题，然后紧急修复，将查询条件和分页不在service层做处理，放到sql中，效率是提升了，自测了两个查询条件没问题，上线了。
结果就是因为自测查询条件没覆盖全，导致有一个查询条件写错了，导致sql报错。。。again。。。再一次紧急修复。。第三次上线正常了。。
总结
出现这些问题最主要的原因
第一： 没有理解需求，想当然的完全复用之前的sql，没想过要改sql。
第二：没有重视性能问题，已经发现了性能很差，但是没有当回事儿
第三：逻辑问题，不应该在service层做分页和数据筛选
第四：自测不够，没有测全，就发版
改正
重视性能，其实只要重视性能，就不会出现这个事儿
网友评论