| 網(wǎng)上看到的一篇文章，結(jié)合自己的經(jīng)驗(yàn)和大家交流一下 對(duì)大量數(shù)據(jù)的分頁(yè)處理問(wèn)題描述：背景1：一客戶通過(guò)IE請(qǐng)求Web服務(wù)器查詢數(shù)據(jù)，而查詢結(jié)果是上千條甚至是上萬(wàn)條記錄，要求查詢結(jié)果傳送到IE客戶端并分頁(yè)顯示。背景2：一客戶通過(guò)IE或者其他方式請(qǐng)求Web服務(wù)器查詢數(shù)據(jù)，而查詢結(jié)果是上千條甚至是上萬(wàn)條記錄，并要求查詢結(jié)果把包傳送到客戶的E-mail中。問(wèn)：對(duì)于這樣的有大量數(shù)據(jù)的結(jié)果集，在Web服務(wù)器端如何有效的處理？可能涉及到的問(wèn)題：1． 內(nèi)存占用大量數(shù)據(jù)的結(jié)果集，可能要占用非常大的內(nèi)存2． 傳輸速度及策略具體的分頁(yè)處理技術(shù) 處理方法1 游標(biāo)查詢 直接使用ResultSet來(lái)處理。ResultSet是直接在數(shù)據(jù)庫(kù)上建立游標(biāo)，然后通過(guò)ResultSet的行位置定位接口來(lái)獲得指定行位置的記錄。當(dāng)用戶第一請(qǐng)求數(shù)據(jù)查詢時(shí)，就執(zhí)行SQL語(yǔ)句查詢，獲得的ResultSet對(duì)象及其要使用的連接對(duì)象都保存到其對(duì)應(yīng)的會(huì)話對(duì)象中。以后的分頁(yè)查詢都通過(guò)第一次執(zhí)行SQL獲得的ResultSet對(duì)象定位取得指定行位置的記錄。最后在用戶不再進(jìn)行分頁(yè)查詢時(shí)或會(huì)話關(guān)閉時(shí)，釋放數(shù)據(jù)庫(kù)連接和ResultSet對(duì)象等數(shù)據(jù)庫(kù)訪問(wèn)資源。說(shuō)明：在用例分頁(yè)查詢的整個(gè)會(huì)話期間，一個(gè)用戶的分頁(yè)查詢就要占用一個(gè)數(shù)據(jù)庫(kù)連接對(duì)象和結(jié)果集的游標(biāo)，這種方式對(duì)數(shù)據(jù)庫(kù)的訪問(wèn)資源占用比較大，并且其利用率不是很高。 所有的數(shù)據(jù)庫(kù)產(chǎn)品。 優(yōu)點(diǎn)：減少了數(shù)據(jù)庫(kù)連接對(duì)象的多次分配獲取，減少了對(duì)數(shù)據(jù)庫(kù)的SQL查詢執(zhí)行。缺點(diǎn)：占用數(shù)據(jù)庫(kù)訪問(wèn)資源－數(shù)據(jù)庫(kù)連接對(duì)象，并占用了數(shù)據(jù)庫(kù)上的資源－游標(biāo)。而這些資源都是十分寶貴的有限制的。結(jié)論：這種的數(shù)據(jù)庫(kù)查詢分頁(yè)處理方式不是最佳的。一般不適用這種方式。 2 定位行集SQL查詢 主要是直接使用數(shù)據(jù)庫(kù)產(chǎn)品的提供的對(duì)查詢的結(jié)果集可定位行范圍的SQL接口技術(shù)。在用戶的分頁(yè)面查詢請(qǐng)求中，每次可取得查詢請(qǐng)求的行范圍的參數(shù)，然后使用這些參數(shù)生產(chǎn)取得指定行范圍的的SQL查詢語(yǔ)句，然后每次請(qǐng)求獲得一個(gè)數(shù)據(jù)庫(kù)連接對(duì)象并執(zhí)行SQL查詢，把查詢的結(jié)果返回給用戶，最后釋放說(shuō)有的數(shù)據(jù)庫(kù)訪問(wèn)資源。說(shuō)明：這種方式需要每次請(qǐng)求時(shí)都要執(zhí)行數(shù)據(jù)庫(kù)的SQL查詢語(yǔ)句；對(duì)數(shù)據(jù)庫(kù)的訪問(wèn)資源是使用完就立即釋放，不白白占用數(shù)據(jù)庫(kù)訪問(wèn)資源。 對(duì)特定（提供了對(duì)查詢結(jié)果集可定位功能的）的數(shù)據(jù)庫(kù)產(chǎn)品。如：Oracle,DB2, PostgreSQL,mySQL等。(MS SQL Server 沒(méi)有提供此技術(shù)。) 如:1． Oracle數(shù)據(jù)庫(kù)使用關(guān)鍵字：rowid或rownum 2． DB2:rowid或rownum ()3． PostgreSQL 使用LIMIT 和 OFFSET4． MySQL 使用Limit 優(yōu)點(diǎn)：這種技術(shù)是直接使用數(shù)據(jù)庫(kù)產(chǎn)品自己提供的可對(duì)查詢結(jié)果集定位行范圍過(guò)濾的功能，因此直接利用了數(shù)據(jù)庫(kù)的性能對(duì)此分頁(yè)查詢的優(yōu)化功能。對(duì)數(shù)據(jù)庫(kù)的訪問(wèn)資源（數(shù)據(jù)庫(kù)連接對(duì)象，數(shù)據(jù)庫(kù)游標(biāo)等）沒(méi)有浪費(fèi)，這些資源的充分重復(fù)的利用。對(duì)查詢的結(jié)果對(duì)Web容器沒(méi)有什么特別要求。缺點(diǎn)：要執(zhí)行多次數(shù)據(jù)庫(kù)SQL查詢操作。對(duì)每次的分頁(yè)面操作請(qǐng)求都要指定相應(yīng)范圍的結(jié)果集來(lái)執(zhí)行SQL語(yǔ)句的數(shù)據(jù)庫(kù)查詢操作，這對(duì)數(shù)據(jù)庫(kù)有一定的影響。對(duì)每次分頁(yè)面查詢請(qǐng)求要頻繁的從Web容器中獲得數(shù)據(jù)庫(kù)訪問(wèn)資源（數(shù)據(jù)庫(kù)連接對(duì)象和數(shù)據(jù)庫(kù)游標(biāo)）。要依賴于具體的數(shù)據(jù)庫(kù)產(chǎn)品。因?yàn)閷?duì)沒(méi)有實(shí)現(xiàn)沒(méi)有提供此技術(shù)的數(shù)據(jù)庫(kù)產(chǎn)品不能使用此方式。結(jié)論：由于每次對(duì)數(shù)據(jù)庫(kù)的SQL查詢操作相對(duì)而言耗用的數(shù)據(jù)資源比較少，并且在實(shí)際用戶的操作中，有可能用戶對(duì)查詢的所有結(jié)果集只是需要查看其中的部分頁(yè)面。因此這種方式是最佳的。 3 特別處理的定位行集SQL查詢 這種方式是在方式2的基礎(chǔ)上針對(duì)不提供對(duì)查詢結(jié)果集行范圍定位的數(shù)據(jù)庫(kù)產(chǎn)品。其在Web容器端的操作邏輯大致和方式2相同。只是先要對(duì)要查詢的數(shù)據(jù)庫(kù)表要有一字段的數(shù)據(jù)能區(qū)別每條不同的數(shù)據(jù)記錄。第一次查詢時(shí)，獲得用來(lái)可唯一標(biāo)識(shí)不同記錄的字段的所有結(jié)果集，并緩存起來(lái)以備后面的分頁(yè)面查詢指定要查詢的結(jié)果集的行范圍。 主要是針對(duì)不同對(duì)查詢行集可定位范圍獲得的數(shù)據(jù)庫(kù)產(chǎn)品，如MS SQL Server等。 假設(shè)從A，B，C三個(gè)表中選取數(shù)據(jù)。且A有字段ID用來(lái)可唯一區(qū)別不同的記錄。那么第一次查詢的時(shí)候，會(huì)查詢兩次1. select A.id from A,B,C where condition.2. 把A的ID緩存到SESSION中?3.從Session中?，F(xiàn)可按照次序來(lái)取得相應(yīng)頁(yè)面范圍的ID來(lái)，并構(gòu)造下一個(gè)查詢語(yǔ)句：select A.name, B.add from A,B,C where condition && ( A.ID in 本頁(yè)面范圍的 ID )以后每次翻頁(yè)的時(shí)候，依次獲得對(duì)應(yīng)頁(yè)的ID只要表中唯一的就可以了。無(wú)所謂大小，順序?這樣，SESSSION緩存的就只是一列而不是所有列了。當(dāng)然，對(duì)于列數(shù)不多的，效果并不好。也可使用存儲(chǔ)過(guò)程實(shí)現(xiàn)，可參照：http://expert.csdn.net/Expert/topic/2365/2365596.xml?temp=.7529261優(yōu)點(diǎn)：同方式2缺點(diǎn)：同方式2；還要在要查詢的數(shù)據(jù)庫(kù)表中建立一個(gè)相應(yīng)的ID,用來(lái)唯一區(qū)別每條記錄。結(jié)論：同方式2。 4 緩存一次SQL查詢的結(jié)果集 優(yōu)點(diǎn)：缺點(diǎn)：既然我們要緩存結(jié)果，那么用戶就可能會(huì)看到過(guò)期的數(shù)據(jù) 說(shuō)明：對(duì)于實(shí)際情況的應(yīng)用來(lái)說(shuō)，一般結(jié)合實(shí)際情況，結(jié)合使用方式2（或方式3）和方式4。如：一個(gè)應(yīng)用場(chǎng)景：對(duì)公司的產(chǎn)品的查詢是經(jīng)常的，但是產(chǎn)品的種類不是很多，這時(shí)可使用緩存方式；但是對(duì)有些查詢結(jié)果集較大，數(shù)據(jù)庫(kù)和Web容器之間的網(wǎng)絡(luò)訪問(wèn)由可能是遠(yuǎn)程的，這時(shí)候可考慮使方式2（或者方式3）。 //----------------------------------------------------------- 以前做的幾個(gè)項(xiàng)目中，大多數(shù)都是采用類似于方式1的分頁(yè)。如果查詢頻繁的話，系統(tǒng)訪問(wèn)速度就是問(wèn)題。 方法2確實(shí)是個(gè)好方法，但是過(guò)于依賴數(shù)據(jù)庫(kù)，并非文章中所提及的“最佳方法”。 個(gè)人認(rèn)為方法1和方法2相結(jié)合，才能達(dá)到較好的效果。即先查詢出較大的結(jié)果集（可能是最大集合的1/100），然后對(duì)該結(jié)果集使用方法1的分頁(yè)。這樣既不用頻繁的訪問(wèn)數(shù)據(jù)庫(kù)，也不會(huì)創(chuàng)造出過(guò)多的對(duì)象。當(dāng)然正如文章中提到的：MS SQL Server 不支持定位技術(shù) >_< ，所以游標(biāo)的定位需要靠程序解決。 方法3好象是方法4的補(bǔ)充了。。。。研究ing 下面是方法4的實(shí)現(xiàn)//關(guān)于分頁(yè)顯示中，因?qū)ο筮^(guò)多而造成的系統(tǒng)速度過(guò)慢問(wèn)題的修改，適合數(shù)據(jù)庫(kù)更新不頻繁的情況 //得到一個(gè)idListList idList = new ArrayList();rs = select id from db where conditionwhile (rs.next){ idList.add(rs.getString("id"));} //根據(jù)idList得到formListList formList = TEST.getInstance().getInfo(idList); //類TEST中具體實(shí)現(xiàn)//創(chuàng)建唯一的instance，只有當(dāng)系統(tǒng)第一次調(diào)用此方法，則創(chuàng)建實(shí)例Map m = new Treemap();rs = select * from dbwhile (rs.next){ TestForm testForm = new TestForm(); testForm.setvalue(...); m.put(TestForm.getF_id(),testForm);}//根據(jù)idList從map中取得相應(yīng)數(shù)據(jù)public List getInfo(List idList){ List infoList = new ArrayList(); for (int i = 0;i //顯示formList中的內(nèi)容 | 
