经过这次优化，接口性能也提升了5倍。
从5s 左右，缩短到1s左右。
但整体效果还不太理想。
5. 第三次优化
经过前面的两次优化，批量查询评价接口性能有一些提升，但耗时还是大于1s。
出现这个问题的根本原因是：一次性查询的数据太多。
那么，我们为什么不限制一下，每次查询的记录条数呢？
第三次优化，限制一次性查询的记录条数。其实之前也做了限制，不过最大是2000条记录，从目前看效果不好。
限制该接口一次只能查200 条记录，如果超过200条则会报错提示。
如果直接对该接口做限制，则可能会导致业务系统出现异常。
为了避免这种情况的发生，必须跟业务系统团队一起讨论一下优化方案。
主要有下面两个方案：
5.1 前端做分页
在结算单列表页中，每个结算单默认只展示1个订单，多余的分页查询。
这样的话，如果按照每页最大100条记录计算的话，结算单和订单最多一次只能查询200条记录。
这就需要业务系统的前端做分页功能 ，同时后端接口要调整支持分页查询。
但目前现状是前端没有多余的开发资源。
由于人手不足的原因，这套方案目前只能暂时搁置。
5.2 分批调用接口
业务系统后端之前是一次性 调用评价查询接口，现在改成分批调用。
