分页-低级错误

前言

早上收到测试发来的邮件，用户关闭订单页面报连接超时，问了其它同事，他们并没有同样的问题(这里是重点 大家可以想想)。

问题分析

超时，肯定是那个地方执行的太久导致的。
下面是出问题的那段代码的逻辑。

		//第一步查询用户订单集合
		
		//遍历订单集合 查询订单详情  每次遍历里面设计两次查库操作
		
		//内存分页    这里真的是惊呆我了

我们想到的第一个排查点就是，订单集合过大，会导致查库操作过多2*集合大小，而且后面也分页了，说明加载的也就是分页大小的订单数据，然后看到邮件有该测试人员的用户数据，然后找到查订单的sql，查了一下数据，发现有六百多跳，相当于查询炒作执行了一千两百多次，一次查询算它10ms这都10s了，不超时才怪。
处理后的程序逻辑

		//第一步查询用户订单分页后的集合
		
		//遍历订单集合 查询订单详情  每次遍历里面设计两次查库操作

发测试环境，测试人员测试通过

优化策略

分页放在后面也是有点迷呀，前面白白做了那么多无用功，你才取一页的数据，解决方案就很简单了，把分页放在第一步就好了，订单列表的数量也就是一页数据的大小。

总结

• 定位到代码块
• 抽出里面的代码执行流程及逻辑
• 分析可能导致程序执行慢的原因
• 根据原因 找到对应的处理方案 测试结果