任务查询反应慢的处理

        大略看了一遍系统，发现自动化测试任务的查询反应有点慢，debug了一下，时间显示为748ms。重新看了一遍处理方法，发现是因为请求数据库的次数过多的原因。当时为了获得任务进度和执行时间处理的逻辑是，先分页查询到20条任务，然后再遍历这些任务，分别从数据库取到对应子任务的状态和执行时间，从而计算出任务的进度和子任务的最早时间。这样最少请求了21次数据库，拖慢了处理时间。 
         重新处理时本想优化sql语句，一次查询出所需数据，由于任务进度和执行时间整合到所属任务中比较麻烦，没能写出来；对于appinfo_id放到子任务表中，也使查询对应的应用版本和类型增添了麻烦，对于这样每条任务只对应一个应用来说，将其放在任务表下更加合适，在子任务表中过于重复，但是现在改变动的太多，就保持原样了。 
         最后修改的逻辑是先分页查询出20条任务，然后将这些任务的id放到一个list中，再用sql语句中的in将这些任务所需的子任务信息一次性查询出来（ibatis中的nullValue可以将已删除查询不到的应用版本信息设置为想要的文字，如：“已删除”）。为了给这些子任务分组，使其能与各个任务对应起来，对应用版本、执行时间、子任务总数、子任务完成数量分别创建空的Map，以id做为key值进行存储所需信息。遍历所有查询的子任务信息，给其对应的任务求出所需的值，对于应用版本由于每条任务对应的子任务信息都相同，只需判断对应id的应用版本为空时，给其赋值即可。重新处理过后，debug显示查询的时间为63ms。 
         请求连接数据库是一个非常耗时的操作，以后一定要谨记，处理数据时尽量减少与数据库的交互。