詭異的分頁代碼失效問題

前言： 之前碰到了一個界面上分頁失效的問題，并為之困擾了數日，后臺定位為排序失效的問題，問題就迎刃而解了... 問題描述： 在界面上的某個分頁功能存在失效的問題，第一頁、第二頁和最后一頁的分頁效果正常，但是中間的分頁數據不變。 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失效的情況下，保證整體排序的有效性，即可解決分頁失效問題。

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com