各大資料庫分頁

⑴ ASP基礎入門:ADO存取資料庫時如何分頁顯示

《動態網站設計十八般武藝 --ASP 篇》一文從第一期至今已和朋友們一起度過了大半個年頭，相信通過在這一段時間中的學習、實踐到再學習、再實踐，大家已經能夠熟練運用 ASP 的內建對象、 ActiveX 組件去編寫一些基本的 ASP 應用程序。從我收到的朋友們的來信中可以明顯的感覺到，大家的 ASP 功力正不斷地提升。最近很多朋友來信希望我寫一些 ASP 在現實運用中的實例。因此，從本期開始我決定將《動態網站設計十八般武藝 --ASP 篇》的定位從介紹和學習 ASP 基礎知識轉向到 ASP 實際運行的探討和深化。應朋友們的要求，在本期中我將給大家著重談一談「ADO 存取資料庫時如何分頁顯示」的問題。
什麼是 ADO 存取資料庫時的分頁顯示？如果你使用過目前眾多網站上的電子公告板程序的話，那你應該會知道電子公告板程序為了提高頁面的讀取速度，一般不會將所有的帖子全部在一頁中羅列出來，而是將其分成多頁顯示，每頁顯示一定數目的帖子數，譬如 20 條。這就是資料庫查詢的分頁顯示，如果你還不明白，去看看 yahoo 等搜索引擎的查詢結果就會明白了。
那麼究竟如何才能做到將資料庫的查詢結果分頁顯示呢？其實方法有很多，但主要有兩種：
一、將資料庫中所有符合查詢條件的記錄一次性的都讀入 recordset 中，存放在內存中，然後通過 ADO Recordset 對象所提供的幾個專門支持分頁處理的屬性： PageSize( 頁大小 )、 PageCount( 頁數目 ) 以及 AbsolutePage( 絕對頁 ) 來管理分頁處理。
二、根據客戶的指示，每次分別從符合查詢條件的記錄中將規定數目的記錄數讀取出來並顯示。
兩者的主要差別在於前者是一次性將所有記錄都讀入內存然後再根據指示來依次做判斷分析從而達到分頁顯示的效果，而後者是先根據指示做出判斷並將規定數目的符合查詢條件的記錄讀入內存，從而直接達到分頁顯示的功能。
我們可以很明顯的感覺到，當資料庫中的記錄數達到上萬或更多時，第一種方法的執行效率將明顯低於第二種方法，因為當每一個客戶查詢頁面時都要將所有符合條件的記錄存放在伺服器內存中，然後塵李在進行分頁等處理，如果同時有超過 100 個的客戶在線查詢，那麼 ASP 應用程序的執行效率將大受影響。但是，當伺服器上資料庫的記錄數以及同時在線的人數並不是很多時，兩者在執行效率上是相差無幾的，此時一般就採用第一種方法，因為第一種方法的 ASP 程序編寫相對第二種方法要簡單明了得多。
在這里作者就以我們常見的 ASP BBS 程序為例，來給大家分析一下如何在 BBS 程序里實現分頁顯示功能，由於我們一般使用的 BBS 程序的資料庫記錄數和同時訪問的人數都不會太多，所以以下程序實例是使用的先前所介紹的第一種分頁顯示方法。
進行 ADO 存取資料庫時的分頁顯示，其實就是對 Recordset 的記錄進行操作。所以我們首先必須了解 Reordset 對象的屬性和方法：
BOF 屬性：目前指標指到 RecordSet 的第一筆。
EOF 屬性：目前指標指到 RecordSet 的最後一筆。
Move 方法：移動指標到 RecordSet 中的某一條記錄。
AbsolutePage 屬性：設定當前記錄的位置是位於哪一頁 AbsolutePosition 屬性：目前指標在 RecordSet 中的位置。
PageCount 屬性：顯示 Recordset 對象包括多少「頁」的數據。
PageSize 屬性：顯示 Recordset 對象每一頁顯示的記錄數。
RecordCount 屬性：顯示 Recordset 對象記錄的總數。
下面讓我們來詳細認識一下這些重要的屬性和方法
一、 BOF 與 EOF 屬性
通常我們在 ASP 程序中編寫代碼來蘆或檢驗 BOF 與 EOF 屬性，從而得知目前指標所指向的 RecordSet 的位置，使用 BOF 與 EOF 屬性，可以得知一個 Recordset 對象是否包含有記錄或者得知移動記錄行是否已經超出該 Recordset 對象的范圍。
如：
% if not rs.eof then ... %
% if not (rs.bof and rs.eof) %
若當前記錄的位置是派嘩遲在一個 Recordset 對象第一行記錄之前時， BOF 屬性返回 true，反之則返回 false。
若當前記錄的位置是在一個 Recordset 對象最後一行記錄之後時， EOF 屬性返回 true，反之則返回 false。
BOF 與 EOF 都為 False：表示指標位於 RecordSet 的當中。
BOF 為 True：目前指標指到 RecordSet 的第一筆記錄。 EOF 為 True：目前指標指到 RecordSet 的最後一筆記錄。
BOF 與 EOF 都為 True：在 RecordSet 里沒有任何記錄。
二、 Move 方法
您可以用 Move 方法移動指標到 RecordSet 中的某一筆記錄，語法如下：
rs.Move NumRecords,Start
這里的「rs」為一個對象變數，表示一個想要移動當當前記錄位置的 Recordset 對象；「NumRecords」是一個正負數運算式，設定當前記錄位置的移動數目；「start」是一個可選的項目，用來指定記錄起始的標簽。
所有的 Recordset 對象都支持 Move 方法，如果 NumRecords 參數大於零，當前記錄位置向末尾的方向移動；如果其小於零，則當前記錄位置向開頭的方向移動；如果一個空的 Recordset 對象調用 Move 方法，將會產生一個錯誤。
MoveFirst 方法：將當前記錄位置移至第一筆記錄。
MoveLast 方法：將當前記錄位置移至最後一筆記錄。
MoveNext 方法：將當前記錄位置移至下一筆記錄。 MovePrevious 方法：將當前記錄位置移至上一筆記錄。
Move [n] 方法：移動指標到第 n 筆記錄， n 由 0 算起。
三、 AbsolutePage 屬性
AbsolutePage 屬性設定當前記錄的位置是位於哪一頁的頁數編號；使用 PageSize 屬性將 Recordset 對象分割為邏輯上的頁數，每一頁的記錄數為 PageSize( 除了最後一頁可能會有少於 PageSize 的記錄數 )。這里必須注意並不是所有的數據提供者都支持此項屬性，因此使用時要小心。
與 AbsolutePosition 屬性相同， AbsolutePage 屬性是以 1 為起始的，若當前記錄為 Recordset 的第一行記錄， AbsolutePage 為 1。可以設定 AbsolutePage 屬性，以移動到一個指定頁的第一行記錄位置。
四、 AbsolutePosition 屬性
若您需要確定目前指標在 RecordSet 中的位置，您可以用 AbsolutePosition 屬性。
AbsolutePosition 屬性的數值為目前指標相對於第一筆的位置，由 1 算起，即第一筆的 AbsolutePosition 為 1。
注意 , 在存取 RecordSet 時，無法保證 RecordSet 每次都以同樣的順序出現。
若要啟用 AbsolutePosition，必須先設定為使用用戶端 cursor( 指針 )， asp 碼如下：
rs2.CursorLocation = 3
五、 PageCount 屬性
使用 PageCount 屬性，決定 Recordset 對象包括多少「頁」的數據。這里的「頁」是數據記錄的集合，大小等於 PageSize 屬性的設定，即使最後一頁的記錄數比 PageSize 的值少，最後一頁也算是 PageCount 的一頁。必須注意也並不是所有的數據提供者都支持此項屬性。
六、 PageSize 屬性
PageSize 屬性是決定 ADO 存取資料庫時如何分頁顯示的關鍵，使用它就可以決定多少記錄組成一個邏輯上的「一頁」。設定並建立一個頁的大小，從而允許使用 AbsolutePage 屬性移到其它邏輯頁的第一條記錄。 PageSize 屬性能隨時被設定。
七、 RecordCount 屬性
這也是一個非常常用和重要的屬性，我們常用 RecordCount 屬性來找出一個 Recordset 對象包括多少條記錄。如：
% totle=RS.RecordCount %
在了解了 Recordset 對象的以上屬性和方法後，我們來考慮一下，如何運用它們來達到我們分頁顯示的目的。首先，我們可以為 PageSize 屬性設置一個值，從而指定從記錄組中取出的構成一個頁的行數；然後通過 RecordCount 屬性來確定記錄的總數；再用記錄總數除以 PageSize 就可得到所顯示的頁面總數；最後通過 AbsolutePage 屬性就能完成對指定頁的訪問。好象很並不復雜呀，下面讓我們來看看程序該如何實現呢？
我們建立這樣一個簡單的 BBS 應用程序，它的資料庫中分別有以下五個欄位：「ID」，每個帖子的自動編號；「subject」，每個帖子的主題；「name」，加帖用戶的姓名； 「email」，用戶的電子郵件地址；「postdate」，加帖的時間。資料庫的 DSN 為「bbs」。我們將顯示帖子分頁的所有步驟放在一個名為「ShowList()」的過程中，方便調用。程序如下：
'----BBS 顯示帖子分頁----
% Sub ShowList() %
%
PgSz=20 '設定開關，指定每一頁所顯示的帖子數目，默認為20帖一頁
Set Conn = Server.CreateObject("ADODB.Connection")
Set RS = Server.CreateObject("ADODB.RecordSet")
sql = "SELECT * FROM message order by ID DESC"
'查詢所有帖子，並按帖子的ID倒序排列
Conn.Open "bbs"
RS.open sql,Conn,1,1
If RS.RecordCount=0 then
response.write " P center對不起，資料庫中沒有相關信息！ /center /P"
else
RS.PageSize = Cint(PgSz) '設定PageSize屬性的值
Total=INT(RS.recordcount / PgSz * -1)*-1 '計算可顯示頁面的總數
PageNo=Request("pageno")
if PageNo="" Then
PageNo = 1
else
#p#副標題#e#
PageNo=PageNo+1
PageNo=PageNo-1
end if
ScrollAction = Request("ScrollAction")
if ScrollAction = " 上一頁 " Then
PageNo=PageNo-1
end if
if ScrollAction = " 下一頁 " Then
PageNo=PageNo+1
end if
if PageNo
1 Then
PageNo = 1
end if
n=1
RS.AbsolutePage = PageNo
Response.Write " CENTER"
position=RS.PageSize*PageNo
pagebegin=position-RS.PageSize+1
if position
RS.RecordCount then
pagend=position
else
pagend= RS.RecordCount
end if
Response.Write " P font color='Navy' B資料庫查詢結果: /B"
Response.Write "(共有"RS.RecordCount "條符合條件的信息,顯示"pagebegin"-"pagend") /font /p"
Response.Write " TABLE WIDTH=600 BORDER=1 CELLPADDING=4 CELLSPACING=0 BGCOLOR=#FFFFFF"
Response.Write " TR BGCOLOR=#5FB5E2 FONT SIZE=2 TD B主題 /B /TD TD B用戶 /B /TD TD BEmail /B /TD TD B發布日期 /B /TD /FONT TR BGCOLOR=#FFFFFF"
Do while not (RS is nothing)
RowCount = RS.PageSize
Do While Not RS.EOF and rowcount 0
If n=1 then
Response.Write " TR BGCOLOR=#FFFFFF"
ELSE
Response.Write " TR BGCOLOR=#EEEEEE"
End If
n=1-n %
TD span style="font-size:9pt" A href='view.asp?key= % =RS("ID")%' % =RS("subject")% /A /span /td
TD span style="font-size:9pt" % =RS("name")% /A /span /td
TD span style="font-size:9pt" a href="mailto: % =RS("email")%" % =RS("email")% /a /span /TD
TD span style="font-size:9pt" % =RS("postdate")% /span /td
/TR
%
RowCount = RowCount - 1
RS.MoveNext
Loop
set RS = RS.NextRecordSet
Loop
Conn.Close
set rs = nothing
set Conn = nothing
%
/TABLE
FORM METHOD=GET ACTION="list.asp"
INPUT TYPE="HIDDEN" NAME="pageno" VALUE=" % =PageNo %"
%
if PageNo 1 Then
response.write " INPUT TYPE=SUBMIT NAME='ScrollAction' VALUE=' 上一頁 '"
end if
if RowCount = 0 and PageNo
Total then
response.write " INPUT TYPE=SUBMIT NAME='ScrollAction' VALUE=' 下一頁 '"
end if
response.write " /FORM"
End if
%
% End Sub %
相信大家都應該能完全讀懂上面的程序，因此作者就不在此詳細解釋了。值得注意的是在這段程序中運用了一個小技巧
INPUT TYPE="HIDDEN" NAME="pageno" VALUE=" % =PageNo %"
，這是用來在每次調用該 ASP 文件時傳遞數據的「暗道」，由於我們需要在每次調用程序時傳遞代表當前頁碼的參數，可能大家會想到使用 session，但是從節省系統資源和通用性來講，用這樣一個隱藏的 form 來傳遞數據將會達到更好的效果。#p#副標題#e#

⑵ 十萬條Access數據表分頁的兩個解決方法

這篇文章主要介紹了Acess數據表分頁的兩個具體的解決方法，詳細內容請參考下文。
後台資料庫用是access,客戶用了一年後說打開界面非常慢,查看了資料庫後發現數據表中的記錄已有五萬多條,自己試過將記錄復制到10 萬條,打開界面非常慢,翻頁也是同樣的問題,我採用的方式是每頁裝入20條記錄,循環寫在表格中顯示出來,再定四個翻頁鍵用來查看數據,但問題是雖然是 每次裝入頁面的記錄只有二十條,但每次要打開記錄集時還是必須一次性裝入所有的記錄,所以才慢。
解決方法磨盯數一：
1.設置一個自增長欄位.並且該欄位為INDEX.
2.由於是 ACCESS ,所以,只能是前台分頁.自增長欄位目的,就是為了實現分頁功能.
1 記錄用戶前頁的最後一個 自增值 ,例如 M .
2 下一頁,取下一頁的開始值.M+1 ,結束值: M+1+1.5*PAGESIZE (注:由於資料庫會有增刪操作,故應該取頁大小應該有一個系數,你可以根據情況自定一個1大的系數.
3 前台循環取 RS 的前 PAGESIZE 條, 寫到一個 新的RS中,並返回.
注瞎首:新的RS是一個無連接的RS .
解決方法二：
十萬條記錄不是 Access 資料庫的極限。何況你的方法不是真正意義上的分頁（應當利用 PageSize 和 AbsolutePage 屬性）。
VBScript code
Set rs = New ADODB.Recordsetrs.CursorLocation = adUseClientrs.PageSize = 20rs.Open "Select * From 客戶", iConc, adOpenKeyset, adLockOptimisticlngPages = rs.PageCountlngCurrentPage = 1
此時打開的記錄集只有 20 條記錄。則運
翻頁時：
VBScript code
If lngCurrentPage
lngPages Then lngCurrentPage = lngCurrentPage + 1 rs.AbsolutePage = lngCurrentPageEnd If

⑶ 結合MySQL資料庫,如何實現分頁功能

第一步：我們可以利用$_GET方法獲取某一個參數的值，在用戶點擊上一頁、下一頁、首頁或者末頁時獲取不同的動態參數

第二培顫步：根據MySQL的limit關鍵字，對動態參數進行SQL語句拼接

將定義每頁顯示的數據條數，在limit第一個參數的位置中，根據地址欄參數的動態變化從毀含而配余敗實現指定從第幾條數據開始顯示數據

⑷ 常見分頁的幾種方式

面試問題就比較好回答了:
我認為可以概括為兩種:
第一種:真分頁,也就是資料庫分頁春腔,需要多少數據取多少數據,適合數據量比較大的情況下使用.
第二種:假分頁,把所有數據都取出來,然後在頁面上進行分頁.
大羨森喊致就是這樣子,當然這只是粗淺的說法兄野.

⑸ 如何實現不同資料庫的數據查詢分頁

有兩種方法
方法回答1：
select top 100 * from tbllendlist where fldserialNo not in ( select top 300100 fldserialNo from tbllendlist order by fldserialNo ) order by fldserialNo
方法2：
SELECT TOP 100 * FROM tbllendlist WHERE (fldserialNo > (SELECT MAX(fldserialNo) FROM (SELECT TOP 300100 fldserialNo FROM tbllendlist ORDER BY fldserialNo) AS T)) ORDER BY fldserialNo

⑹ 怎樣解決資料庫中文本的分段、分頁顯示的問題

最好的辦法是在插入數據的時候就將數據的格式重新編寫，然後在讀取數據的時候根據標簽，比如：<p>……</p>這種的，計算你要清胡截取的文字的數量後，先將文字HTML樣式去掉，只計算文字的數量，然後判斷開始和虧局結束標簽，如果結束標簽正好符合條件那麼就截取到結束標簽就可以了，如答空攔果不符合要求，又相差不大的話，也可以只截取到結束標簽；反之則截取到下一個結束標簽；
對於你這種情況，現在來說，只能去除html樣式，然後計算文字數量，根據結束標簽進行截取了

⑺ 分頁是什麼意思

問題一：資料庫 分頁是什麼意思? 資料庫分頁也是在資料庫里寫查詢語句，不同的是查詢的都是指定條數到指定條數的數據，不是一次性把數據全查出來。

問題二：分頁是什麼意思 後台分頁則是指後台僅返回某個范圍內的數據，如第100到200條的數據，每次都需要與後台進行查詢交互。
因為把所有的數據返回到前台時，前台壓力太大，數據從後台傳到前台所需要的時間太多，導致系統變得響應很慢。這時候就要考慮使用後台分頁了，每次只查詢所需要的數據，由後台返回，這樣每次只需要返回少量的數據就可以了。

問題三：word中的分頁符是什麼含滾意思？ word文檔是連續文檔，前一個段落直接連著後一個段落。
如果想到某一段以後，後面就不在連著了，下一個段落放到下一頁去，這時候就需要在這個段落後面加一個分頁符。
具體分頁符的插入方法可以參考經驗裡面的這篇文檔。
jingyan./...3

問題四：什麼叫「分頁查詢」？ 當數據量過大時，可能會導致各種各樣的問題發生，例如：伺服器資源被耗盡，因數據傳輸量過大而使處理超時，等等。最終都會導致查詢無法完成。
解決這個問題的一個策略就是「分頁查詢」，也就是說不要一次性查詢所有的數據，每次只查詢一「頁「的談橘余數據。這樣分批次地進行處理，可以呈現出很好的用戶體驗，對伺服器資源的消耗也不大。
打一個比方，有很多很多人要過河，而只有一條船擺渡。若讓所有人都上船，肯定會導致沉船（資源耗盡）；若換一條超大的船，除了換船要很高的成本外，上船下船也要耗費很長時間。
所以最好的解決方法是，根據船的容量，每次只上一部分人。等這一船人過河以後，再擺渡下一批人。

問題五：word里每章節要求獨立分頁 什麼意思 1.打開要編輯的word 文檔。
2.將滑鼠游標移到你需要分頁的地方，
3.在菜單欄中找到頁面布局選項卡，選擇分隔符。
4.點擊分隔符。在下拉列表中選擇分頁符，點擊選擇即設置成功，將會福到成功分頁。
5.還有更為簡單的一種方法，首先將滑鼠游標放在需要分頁的地方。
6.然後按住ctrl鍵再按回車鍵，這樣便一次性達到了分頁的目的。使用起來非常的方便快捷。

問題六：什麼是分頁顯示？ 分頁啊，應該是一頁顯貳不完，分多頁顯示。
比如：資料庫有2萬條記錄，在頁面顯示的時候一個頁面顯示不完，就採用分頁，每頁顯示多少條，就有「首頁 上一頁 下一頁 尾頁」
不知道是不是問的這個

問題七：word中段落設置中段前分頁是什麼意思？ 直接從當前頁跳至下頁.就是你分段的時候敲回車就會跳到下頁.

問題八：頁面文件、分頁文件,「頁面」、「分頁」是什麼意思啊? 頁面文件，是指操作系統反映構建並使用虛擬內存的硬碟空間大小所使用的文件。要整理頁面文件，首先將頁面文件從原先所在的驅動器移動到其他驅動器，然後對原來驅動器進行整理，最後再將頁面文件移回到原驅動器上，此時頁面文件就會存放在伍液連續的磁碟空間中了。具體來說，在 windows操作系統下（Windows 2000/XP）pagefile.sys這個文件，它就是系統頁面文件(也就是大家熟知的虛擬內存文件)，它的大小取決於打開的程序多少和你原先設置頁面文件的最小最大值，是不斷變化的，有時可能只有幾十M，有時則達到600M以上。
什麼是分頁？
無論你的NT伺服器的內存有多大，它總是顯得不夠充足。當物理RAM從低端開始運行時，Windows NT使用了分頁文件Pagefile.sys。為了運行不同的進程和應用程序，Pagefile.sys給物理內存分配了一些空間。在這些空間內允許交換數據頁。
顯然，系統在文件系統緩存中查找數據而不是在驅動器上搜索數據會提高系統的性能。太多的搜索操作會使處理器停頓下來。這就是短語「買更多的內存」成為計算機時代的陳詞濫調的原因之一：RAM是你的朋友。管理內存可使你的「朋友」更高效。
Windows NT下的Windows Task Manager （[Ctrl][Alt][Delete] | Task Manager）是一個可以為訪問內存使用情況提供快捷重要信息的察看工具。考慮物理內存的大小並計算MEM Usage計數器的值，Memory Usage History提供了內存活動的即時情況。正如圖2.2.A所示，把CPU Usage計數器和CPU Usage History與MEM Usage計數器一作比較，就可以簡單地得到性能的總的評價。如果你必須決定是否要立刻啟動
Diskperf以進一步調查分頁過多問題那就非常便利了。
Windows NT的分頁文件可以通過Control Panel |System | Performance 標簽| Virtual Memo錠y進行管理。在這里，你可以控制分頁文件的幾個設置（包括大小和區域）。顯然，你可以允許系統對它進行處理，但是為了獲得最佳配置還是使用Vitual Memory Manager (VMM)為好。
2.2.2 Windows NT分頁文件的基本原則
Windows NT最初通過在物理RAM的數量上加上12MB以設定開始的分頁文件大小。這12MB考慮到在系統故障時分頁文件內容可被傾倒到一個日誌中以防萬一。如果看見了「停止」框和接著出現藍屏死機，你就在操作中遇上了這個問題。如果開始的分頁文件的大小小於這個數（物理RAM的數量上加上12MB），就會開始收到Running Out Of Memory消息。
Windows NT操作系統和其應用程序使用了大約10MB的RAM。所以，應該從物理RAM的數量上減去這個值。這會給你充分的迴旋餘地決定你的伺服器的內存要求。
Windows NT要求分頁文件的最小值為2MB。如果分頁文件太小或者根本不存在，啟動時就會出現警告消息。
分頁文件應該總是遵循RAM的最小值+12的規則。在任何情況下，分頁文件都不能比伺服器中的RAM的大小小。如果系統有32 MB的物理RAM，加上12MB後分頁文件總的大小就是44MB。顯然，分頁文件越大於好。但是，我的意思是增加對物理RAM的投資，而不是簡單地增加分頁文件的大小。如果沒有足夠的RAM，驅動器就會花太多的時間對分頁文件進行讀寫。這只會降低你的伺服器的速度，如果你不得......>>

問題九：虛擬內存里的分頁是什麼意思? 分頁文件：硬碟上一個或者多個隱藏文件pagefile.sys，Windows用於存儲未存入內存的部分程序和數據文件。頁面文件和物理內存或隨機存取內存（RAM）構成了虛擬內存。Windows會根據需要將數據從頁面文件移至內存，或將數據從內存移至頁面文件以便為新數據釋放內存。也叫「交換文件」。
望採納！！！

問題十：列印機自動分頁什麼意思 根據你頁面設置的尺寸大小
列印機將會自動根據你頁面設置的尺寸大小將文檔分頁列印。

⑻ 求助大神Oracle分頁

分頁的SQL語句
如果我們是通過JDBC的方式訪問資料庫,那麼就有必要根據資料庫類型採取不同的SQL分頁語句,對於MySQL資料庫,我們可以採用limit語句進行分頁,對於Oracle資料庫,我們可以採用rownum的方式進行分頁.
(1)MySql的Limit m,n語句
Limit後的兩個參數中，參數m是起始下標，它從0開始；參數n是返回的記錄數。我們需要分頁的話指定這兩個值即可
(2)Oracle資料庫的rownum
在Oracle資料庫中,分頁方式沒有MySql這樣簡單攜猜,它需要依靠rownum來實現.
Rownum表示一條記錄的行號,值得注意的是它在獲取每一行後才賦予.因此,想指定rownum的區間來取得分頁數據在一層查詢語句中是無法做到的,要分頁還要進行一次查詢.
SELECT * FROM
(
SELECT A.*, ROWNUM RN
FROM (SELECT * FROM TABLE_NAME) A
WHERE ROWNUM <= 40
)
WHERE RN >= 21
其中最內層的查詢SELECT * FROM TABLE_NAME表示不進行翻頁的原始查詢語句。ROWNUM <= 40和RN >= 21控制分頁查詢的每頁的范圍。
上面給出的這個分頁查詢語句，在大多數情況擁有較高的效率。分頁的目的就是控制輸出結果集大小，將結果盡快的返回。在上面的分頁查詢語句中，這種考慮主要體現在WHERE ROWNUM <= 40這句上。
選擇第21到40條記錄存在兩種方法，一種是上面例子中展示臘或的在查詢的第二層通過ROWNUM <= 40來控制最大值，在查詢的最外層控制最小值。而另一種方式是去掉查詢第二層的WHERE ROWNUM <= 40語句，在查詢的最外層控制分頁的最小值和最大值。這是，查詢語句如下：
SELECT * FROM
(
SELECT A.*, ROWNUM RN
FROM (SELECT * FROM TABLE_NAME) A
)
WHERE RN BETWEEN 21 AND 40
對比這兩種寫法，絕大多數的情況下，第一個查詢的效率比第二輪隱伍個高得多。
這是由於CBO優化模式下，Oracle可以將外層的查詢條件推到內層查詢中，以提高內層查詢的執行效率。對於第一個查詢語句，第二層的查詢條件WHERE ROWNUM <= 40就可以被Oracle推入到內層查詢中，這樣Oracle查詢的結果一旦超過了ROWNUM限制條件，就終止查詢將結果返回了。
而第二個查詢語句，由於查詢條件BETWEEN 21 AND 40是存在於查詢的第三層，而Oracle無法將第三層的查詢條件推到最內層（即使推到最內層也沒有意義，因為最內層查詢不知道RN代表什麼）。因此，對於第二個查詢語句，Oracle最內層返回給中間層的是所有滿足條件的數據，而中間層返回給最外層的也是所有數據。數據的過濾在最外層完成，顯然這個效率要比第一個查詢低得多。
上面分析的查詢不僅僅是針對單表的簡單查詢，對於最內層查詢是復雜的多表聯合查詢或最內層查詢包含排序的情況一樣有效。
附：分頁技術實現：http: //www. blogjava.net/sitinspring/archive/2008/09/13/228771. html
附：Oracle分頁查詢：http://yangtingkun.itpub.net/post/468/109834
附：使用 PHP 和 Oracle 實施分頁結果集：http: //www. oracle.com/technology/global/cn/pub/articles/oracle_php_cookbook/fuecks_paged. html
其實分頁技術還有很多其它技術，比如：Struts、hibernate等等都可實現。

⑼ 求教，mysql千萬級數據多表查詢做分頁該如何優化

查詢指定的記錄最好通過Id進行in查詢來獲得真實的數據.其實不是最好而是必須，也就是你應該先查詢出復合的ID列表,通過in查詢來獲得數據
我們來做一個測試ipdatas表：
CREATE TABLE `ipdatas` (
`id` INT(11) NOT NULL AUTO_INCREMENT,
`uid` INT(8) NOT NULL DEFAULT '0',
`ipaddress` VARCHAR(50) NOT NULL,
`source` VARCHAR(255) DEFAULT NULL,
`track` VARCHAR(255) DEFAULT NULL,
`entrance` VARCHAR(255) DEFAULT NULL,
`createdtime` DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
`createddate` DATE NOT NULL DEFAULT '0000-00-00',
PRIMARY KEY (`id`),
KEY `uid` (`uid`)
) ENGINE=MYISAM AUTO_INCREMENT=67086110 DEFAULT CHARSET=utf8;
這是我們做的廣告聯盟的推廣ip數據記錄表，由於我也不是mysql的DBA所以這里咱們僅僅是測試
因為原來裡面有大概7015291條數據
這里我們通過jdbc的batch插入6000萬條數據到此表當中「JDBC插入6000W條數據用時:9999297ms」；
大概用了兩個多小時,這裡面我用的是batch大小大概在1w多每次提交,還有一點是每次提交的數據都很小，而且這里用的myisam數據表，因為我需要知道mysql資料庫的大小以及索引數據的大小結果是
ipdatas.MYD 3.99 GB (4,288,979,008 位元組)
ipdatas.MYI 1.28 GB (1,377,600,512 位元組)
這裡面我要說的是如果真的是大數據如果時間需要索引還是最好改成數字欄位,索引的大小和查詢速度都比時間欄位可觀。
步入正題:
1.全表搜索
返回結構是67015297條數據
SELECT COUNT(id) FROM ipdatas;
SELECT COUNT(uid) FROM ipdatas;
SELECT COUNT(*) FROM ipdatas;
首先這兩個全表數據查詢速度很快,mysql中包含數據字典應該保留了資料庫中的最大條數
查詢索引條件
SELECT COUNT(*) FROM ipdatas WHERE uid=1; 返回結果時間:2分31秒594
SELECT COUNT(id) FROM ipdatas WHERE uid=1; 返回結果時間:1分29秒609
SELECT COUNT(uid) FROM ipdatas WHERE uid=1; 返回結果時間:2分41秒813
第二次查詢都比較快因為mysql中是有緩存區的所以增大緩存區的大小可以解決很多查詢的優化，真可謂緩存無處不在啊在程序開發中也是層層都是緩存
查詢數據
第一條開始查詢
SELECT * FROM ipdatas ORDER BY id DESC LIMIT 1,10 ; 31毫秒
SELECT * FROM ipdatas LIMIT 1,10 ; 15ms

⑽ mysql資料庫分頁

很多應用往往只展示最新或最熱門的幾條記錄，但為了舊記錄仍然可訪問，所以就需要個分頁的導航欄。然而，如何通過MySQL更好的實現分頁，始終是比較令人頭疼的問題。雖然沒有拿來就能用的解決辦法，但了解資料庫的底層或多或少有助於優化分頁查詢。

我們先從一個常用但性能很差的查詢來看一看。

SELECT *
FROM city
ORDER BY id DESC
LIMIT 0, 15

這個查詢耗時0.00sec。So，這個查詢有什麼問題呢？實際上，這個查詢語句和參數都沒有問題，因為它用到了下面表的主鍵，而且只讀取15條記錄。

CREATE TABLE city (
id int(10) unsigned NOT NULL AUTO_INCREMENT,
city varchar(128) NOT NULL,
PRIMARY KEY (id)
) ENGINE=InnoDB;

真正的問題在於offset(分頁偏移量)很大的時候，像下面這樣：

SELECT *
FROM city
ORDER BY id DESC
LIMIT 100000, 15;

上面的查詢在有2M行記錄時需要0.22sec，通過EXPLAIN查看SQL的執行計劃可以發現該SQL檢索了100015行，但最後只需要15行。大的分頁偏移量會增加使用的數據，MySQL會將大量最終不會使用的數據載入到內存中。就算我們假設大部分網站的用戶只訪問前幾頁數據，但少量的大的分頁偏移量的請求也會對整個系統造成危害。Facebook意識到了這一點，但Facebook並沒有為了每秒可以處理更多的請求而去優化資料庫，而是將重心放在將請求響應時間的方差變小。

對於分頁請求，還有一個信息也很重要，就是總共的記錄數。我們可以通過下面的查詢很容易的獲取總的記錄數。

SELECT COUNT(*)
FROM city;

然而，上面的SQL在採用InnoDB為存儲引擎時需要耗費9.28sec。一個不正確的優化是採用 SQL_CALC_FOUND_ROWS,SQL_CALC_FOUND_ROWS 可以在能夠在分頁查詢時事先准備好符合條件的記錄數，隨後只要執行一句 select FOUND_ROWS(); 就能獲得總記錄數。但是在大多數情況下，查詢語句簡短並不意味著性能的提高。不幸的是，這種分頁查詢方式在許多主流框架中都有用到，下面看看這個語句的查詢性能。

SELECT SQL_CALC_FOUND_ROWS *
FROM city
ORDER BY id DESC
LIMIT 100000, 15;

這個語句耗時20.02sec，是上一個的兩倍。事實證明使用 SQL_CALC_FOUND_ROWS 做分頁是很糟糕的想法。
下面來看看到底如何優化。文章分為兩部分，第一部分是如何獲取記錄的總數目，第二部分是獲取真正的記錄。

高效的計算行數

如果採用的引擎是MyISAM，可以直接執行COUNT(*)去獲取行數即可。相似的，在堆表中也會將行數存儲到表的元信息中。但如果引擎是InnoDB情況就會復雜一些，因為InnoDB不保存表的具體行數。

我們可以將行數緩存起來，然後可以通過一個守護進程定期更新或者用戶的某些操作導致緩存失效時，執行下面的語句：

SELECT COUNT(*)
FROM city
USE INDEX(PRIMARY);

獲取記錄

下面進入這篇文章最重要的部分，獲取分頁要展示的記錄。上面已經說過了，大的偏移量會影響性能，所以我們要重寫查詢語句。為了演示，我們創建一個新的表「news」，按照時事性排序(最新發布的在最前面)，實現一個高性能的分頁。為了簡單，我們就假設最新發布的新聞的Id也是最大的。

CREATE TABLE news(
id INT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
title VARCHAR(128) NOT NULL
) ENGINE=InnoDB;

一個比較高效的方式是基於用戶展示的最後一個新聞Id。查詢下一頁的語句如下，需要傳入當前頁面展示的最後一個Id。

SELECT *
FROM news WHERE id < $last_id
ORDER BY id DESC
LIMIT $perpage

查詢上一頁的語句類似，只不過需要傳入當前頁的第一個Id，並且要逆序。

SELECT *
FROM news WHERE id > $last_id
ORDER BY id ASC
LIMIT $perpage

上面的查詢方式適合實現簡易的分頁，即不顯示具體的頁數導航，只顯示「上一頁」和「下一頁」，例如博客中頁腳顯示「上一頁」，「下一頁」的按鈕。但如果要實現真正的頁面導航還是很難的,下面看看另一種方式。

SELECT id
FROM (
SELECT id, ((@cnt:= @cnt + 1) + $perpage - 1) % $perpage cnt
FROM news
JOIN (SELECT @cnt:= 0)T
WHERE id < $last_id
ORDER BY id DESC
LIMIT $perpage * $buttons
)C
WHERE cnt = 0;

通過上面的語句可以為每一個分頁的按鈕計算出一個offset對應的id。這種方法還有一個好處。假設，網站上正在發布一片新的文章，那麼所有文章的位置都會往後移一位，所以如果用戶在發布文章時換頁，那麼他會看見一篇文章兩次。如果固定了每個按鈕的offset Id，這個問題就迎刃而解了。Mark Callaghan發表過一篇類似的博客，利用了組合索引和兩個位置變數，但是基本思想是一致的。

如果表中的記錄很少被刪除、修改，還可以將記錄對應的頁碼存儲到表中，並在該列上創建合適的索引。採用這種方式，當新增一個記錄的時候，需要執行下面的查詢重新生成對應的頁號。

SET p:= 0;
UPDATE news SET page=CEIL((p:= p + 1) / $perpage) ORDER BY id DESC;

當然，也可以新增一個專用於分頁的表，可以用個後台程序來維護。

UPDATE pagination T
JOIN (
SELECT id, CEIL((p:= p + 1) / $perpage) page
FROM news
ORDER BY id
)C
ON C.id = T.id
SET T.page = C.page;

現在想獲取任意一頁的元素就很簡單了：

SELECT *
FROM news A
JOIN pagination B ON A.id=B.ID
WHERE page=$offset;

還有另外一種與上種方法比較相似的方法來做分頁，這種方式比較試用於數據集相對小，並且沒有可用的索引的情況下—比如處理搜索結果時。在一個普通的伺服器上執行下面的查詢，當有2M條記錄時，要耗費2sec左右。這種方式比較簡單，創建一個用來存儲所有Id的臨時表即可(這也是最耗費性能的地方)。

CREATE TEMPORARY TABLE _tmp (KEY SORT(random))
SELECT id, FLOOR(RAND() * 0x8000000) random
FROM city;

ALTER TABLE _tmp ADD OFFSET INT UNSIGNED PRIMARY KEY AUTO_INCREMENT, DROP INDEX SORT,ORDER BY random;

接下來就可以向下面一樣執行分頁查詢了。

SELECT *
FROM _tmp
WHERE OFFSET >= $offset
ORDER BY OFFSET
LIMIT $perpage;

簡單來說，對於分頁的優化就是。。。避免數據量大時掃描過多的記錄。