前言： 之前碰到了一个界面上分页失效的问题，并为之困扰了数日，后台定位为排序失效的问题，问题就迎刃而解了... 问题描述： 在界面上的某个分页功能存在失效的问题，第一页、第二页和最后一页的分页效果正常，但是中间的分页数据不变。 QA提了一个关于此的

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

问题描述：

在界面上的某个分页功能存在失效的问题，第一页、第二页和最后一页的分页效果正常，但是中间的分页数据不变。 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

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

问题的解决

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