詭異的分頁代碼失效問題，分頁失效

詭異的分頁代碼失效問題，分頁失效

前言： 之前碰到了一個介面上分頁失效的問題，並為之困擾了數日，後台定位為排序失效的問題，問題就迎刃而解了...

問題描述：

     在介面上的某個分頁功能存在失效的問題，第一頁、第二頁和最後一頁的分頁效果正常，但是中間的分頁資料不變。 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