诡异的分页代码失效问题

前言： 之前碰到了一个界面上分页失效的问题，并为之困扰了数日，后台定位为排序失效的问题，问题就迎刃而解了...

问题描述：

     在界面上的某个分页功能存在失效的问题，第一页、第二页和最后一页的分页效果正常，但是中间的分页数据不变。 QA提了一个关于此的Bug.

问题分析：

  1.  分析界面分页代码

       界面分页的代码属于在项目使用较多的组件，关于失效分页部分的代码无特殊的定制和使用。

   2.  前端和后台端交互的分析

        基于HTTP的监控工具，发现分页请求的请求数据一切正常，分页的start/limit数据正确，过滤条件是正确的，排除前端问题。

   3.   后台的代码分析

        后台的代码是基于Hibernate实现的DAO查询分析，代码基于基类的常规查询，无特殊代码存在。而且这些基类的常规查询被项目中不同的模块所使用，其他模块功能正常。

        故对这些查询的代码是否存在问题，持怀疑态度。

  4.  怀疑生成的SQL是否存在问题

        打印出在查询中使用的SQL语句，经过分析，SQL也不存在问题。其中使用了log4jdbc来监控sql执行。

  5.  基于查询中使用的SQL在Oracle的plsql中直接运行SQL

        结果发现，在50~75， 75-~100等区间，的确查询数据不变。 SQL语句：

 select *
          from (select row_.*, rownum rownum_
            from (select this_.id          as id25_0_,
                         this_.create_time as create2_25_0_,
                         this_.creator     as creator25_0_,
                         this_.modify_time as modify4_25_0_,
                         this_.updater     as updater25_0_,
                         this_.version     as version25_0_,
                         this_.bank_id     as bank7_25_0_,
                         this_.bank_name   as bank8_25_0_,
                         this_.chk_comment as chk9_25_0_,
                         this_.chk_status  as chk10_25_0_,
                         this_.cup_bank_id as cup11_25_0_,
                         this_.del_status  as del12_25_0_,
                         this_.smp_name    as smp13_25_0_,
                         this_.status      as status25_0_
                    from ns_para_bank this_
                   where this_.chk_status = '02'
                     and this_.chk_status = '02'
                     and this_.del_status = '01'
                   order by this_.modify_time desc
                   ) row_
           where rownum <= 100)
         where rownum_ > 75

6.   后怀疑是排序字段modifyTime问题

     经过排查，发现大部分的modifiedTime字段的数据为空，故导致了排序失效；由于排序失效，引发了分页数据不变的问题

问题的解决

    为排序条件新增了一个排序字段， 在modified_time失效的情况下，保证整体排序的有效性，即可解决分页失效问题。

附录

    1.  Oralce之rownum的使用方法  http://blog.csdn.net/lcj8/article/details/4720032