建站
咨詢
售后
建站咨詢
新聞中心
導(dǎo)讀：數(shù)據(jù)庫操作過程中有通用的分頁存儲過程，高效的分頁存儲過程。但是，這些并沒有從根本上解決性能問題。我們知道對于相同的查詢，如果你限制每頁返回10條記錄和每頁返回20條記錄比，雖然10條記錄在網(wǎng)絡(luò)和返回結(jié)果時會比20條記錄要稍稍占一點優(yōu)勢。但是它要花比20條記錄時2倍的訪問次數(shù)，因此從總的資源消耗來看10條記錄會占用更多的資源。但是用戶的操作你永遠(yuǎn)是無法預(yù)測的，它可能只是看了第1頁然后就退出了。我想一般用戶也很少會去查看第20頁之后的信息吧，除非他是釣魚愛好者！因此，在確定每頁多少條記錄時沒有標(biāo)準(zhǔn)。同時，一般的分頁過程的查詢條件都是動態(tài)的，用戶可以任意的排序。因此，這樣的查詢你無法確定應(yīng)該在哪些字段上創(chuàng)建索引合適。這樣的查詢一般來說都是很低效的。因為動態(tài)，所以你的分頁過程可能每次都需要重新編譯才能得到最優(yōu)的執(zhí)行計劃。
為疊彩等地區(qū)用戶提供了全套網(wǎng)頁設(shè)計制作服務(wù)，及疊彩網(wǎng)站建設(shè)行業(yè)解決方案。主營業(yè)務(wù)為成都網(wǎng)站建設(shè)、成都做網(wǎng)站、疊彩網(wǎng)站設(shè)計，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務(wù)。我們深信只要達(dá)到每一位用戶的要求，就會得到認(rèn)可，從而選擇與我們長期合作。這樣，我們也可以走得更遠(yuǎn)！
那么是不是我們把每頁返回的記錄數(shù)調(diào)整的越大越好，或是一次把全部的結(jié)果返回給客戶？我們知道SQLServer會把最終的結(jié)果保存到數(shù)據(jù)緩沖區(qū)中。你每次請求的SQL語句在執(zhí)行之前會在服務(wù)端預(yù)先分配估計結(jié)果集大小的可用物理內(nèi)存，除非你查詢的結(jié)果集已經(jīng)全部存在于緩存中了。如果遲遲不能預(yù)先分配能夠保存最終結(jié)果的可用物理內(nèi)存，則這個查詢最終就會以超時而結(jié)束。同時，分頁過程中一般都會對結(jié)果集進行排序。而排序、Hash聯(lián)結(jié)、Hash聚合等操作都需要占用大量內(nèi)存，這無疑是雪上加霜。如果你使用的是SQL2005，在SQLSERVER的安裝目錄下的LOG文件夾下會看到默認(rèn)跟蹤所創(chuàng)建的trc文件，如果你看到Sort Warning、Hash Warning，說明你排序的結(jié)果集太大了，排序操作正在等待分配可用的內(nèi)存?；蚴莌ash操作時發(fā)生了遞歸哈希聯(lián)接或哈希援助，詳見聯(lián)機文檔。
在數(shù)據(jù)庫的設(shè)置中有兩個選項：最小查詢內(nèi)存和查詢等待時間，我們一般都不需要去調(diào)整這兩個選項。前者就是你的查詢在排序、Hash等需要額外內(nèi)存操作時，應(yīng)該分配到的最小可用內(nèi)存。后者是控制這個查詢在沒有分配到相關(guān)的資源時所等待的最長時間。如果是-1，則等待25倍于估計執(zhí)行時間的時長。否則，超時退出。
有時候，你在測試機上運行的SQL語句是很高效的。但是，當(dāng)正式服務(wù)器資源緊張時，你的這些高效SQL語句將會以一種不可思議的方式執(zhí)行，因為SQL優(yōu)化引擎所選擇的最優(yōu)執(zhí)行計劃是根據(jù)服務(wù)器當(dāng)前負(fù)載而定的。歸根結(jié)底，都是因為內(nèi)存不足導(dǎo)致你的查詢在事先分配可用內(nèi)存時產(chǎn)生等待。而內(nèi)存不足的原因很大程度上是因為有大量的表掃描所引起的。如果生產(chǎn)機同時為幾個系統(tǒng)提供服務(wù)，如果有一個系統(tǒng)的SQL很糟糕。它就會把其它的系統(tǒng)都拖跨。面對這樣的系統(tǒng)你也只能望洋興嘆了！
關(guān)于分頁過程中top的使用，我在前面的總結(jié)中已經(jīng)提到過。因為top操作是非關(guān)系操作，我們應(yīng)該限制非關(guān)系操作的結(jié)果集大小。因此你應(yīng)該先根據(jù)排序的字段，把排序字段所在表的主鍵值查找出來后，再去和其它的表關(guān)聯(lián)查找相關(guān)信息。詳見 對數(shù)據(jù)進行排序 的第二部分介紹。
基于上面介紹的頁記錄數(shù)和訪問次數(shù)之間的矛盾，取一個折中的辦法。我們能不能在用戶第一次查詢時把返回的結(jié)果保存到一個被持久化的表中呢？表的名稱你可以用登錄用戶的名稱加一些什么標(biāo)志。也許你會擔(dān)心向這些用戶表中插入記錄會影響到數(shù)據(jù)庫的日志操作？我們一般都會使用SELECT INTO來創(chuàng)建這些用戶表。如果數(shù)據(jù)庫的恢復(fù)模式為FULL，頻繁的寫日志操作被排隊，肯定會對性能造成負(fù)面影響。那么我們可不可以為這些用戶表單獨創(chuàng)建一個數(shù)據(jù)庫，這個數(shù)據(jù)庫的恢復(fù)模式simple。此時的SELECT INTO會按最小日志記錄，因此不會受日志的太大影響。你的分頁的存儲過程中引用此數(shù)據(jù)庫中的相關(guān)的表。
SELECT TOP 400 C1.*,ROW_NUMBER() OVER(ORDER BY C1.CompanyName) AS Line
INTO tom_fu FROM dbo.Customers C1
我之所以加了一個400是不想發(fā)生太多的I/O操作，就像上面說的用戶一般不會查看第20頁后的記錄。但如果你要返回總的記錄數(shù)用于計算總共的頁數(shù)時，使用TOP n進行填充表時就不行了。你可能只有再運行一次查詢count()的操作了，即便這樣也不要帶著order by來取count。如果用戶不是特別關(guān)心記錄的總數(shù)，最好就是忽略掉這一操作?；蛘吣愀鶕?jù)你查詢返回的記錄數(shù)多少，有計劃的把TOP n省略掉，把全部的記錄都填充至臨時的用戶表中。有了ROW_NUMBER()的編號，你就可以找到相應(yīng)的頁的記錄。這時，你的過程里不但要傳入每頁的記錄數(shù)、當(dāng)前的頁數(shù)還有查詢的條件之外，還要另外傳入一個是否創(chuàng)建這個用戶表的標(biāo)志。當(dāng)用戶改變了查詢條件、排序規(guī)則時重新查詢原始表用于創(chuàng)建這個臨時用戶表。如果排序規(guī)則的改變不會影響結(jié)果集，這時你也可以加一排序規(guī)則改變的標(biāo)志，直接對已經(jīng)查詢出的結(jié)果進行一次排序。不管怎樣，接下來的查詢，將只對這個臨時用戶表進行查詢，從而提高了查詢速度。因為這個臨時創(chuàng)建的用戶表記錄數(shù)并不多，表掃描這時和索引查找性能不相上下。同時，如果你要對這個臨時表創(chuàng)建索引，也會增加額外的資源開銷，因此我沒有想在上面創(chuàng)建索引的想法。當(dāng)查詢不同的頁時，直接對表進行掃描就可以了。然后，我們能不能把已經(jīng)返回給客戶的頁面記錄緩存起來？這時，當(dāng)然不能用session，因為這要占用大量WEB服務(wù)器內(nèi)存。你只能把返回的結(jié)果保存到客戶的機器上，cookie看來是個不錯的選擇。通過編程的方式來記錄這些記錄所在的頁面。這時，你首先在cookie中判斷此頁內(nèi)容是否存在，如果是已經(jīng)訪問過的頁面，不用再訪問服務(wù)器。用戶高興，服務(wù)器也輕松！
上面是創(chuàng)建表相關(guān)的操作，那如何刪除這些臨時創(chuàng)建的用戶表呢？可以在頁面跳轉(zhuǎn)時，可以在session過期時，可以在你確定用戶不在需要這些臨時用戶表時發(fā)送一個刪除此臨時用戶表的命令。但是，如果用戶意外關(guān)閉時，可能這個臨時的用戶表就不可能被我們顯示的刪除了。因此，可能還需要一個類似.NET垃圾收集的機制來定期的刪除這些不再使用的臨時用戶表?？梢酝ㄟ^程序，也可以通過SQLServer的作業(yè)，我們知道你創(chuàng)建的表在sys.tables中都會得到它的create_date和modify_date，我們可以用來清除這些被物化的表。不管怎樣，你都應(yīng)該想辦法確保盡早的刪除這些臨時用戶表，以防止占用太多的磁盤空間。
這就是我要為大家介紹的數(shù)據(jù)庫分頁操作的全部內(nèi)容，相信通過上文的學(xué)習(xí)，現(xiàn)在大家對數(shù)據(jù)庫分頁的操作已經(jīng)有了很多的了解，希望大家都能夠從中有所收獲。
新聞名稱：詳解數(shù)據(jù)庫分頁操作
分享地址：http://www.dlmjj.cn/article/dpisdsd.html
