前言
之前經常思考的乙個問題,資料庫分表後,分頁怎麼做才是最好的方案呢?今天就來整理一波.
由來首先是由來,資料量增大,一張表資料太多的話,會使用分表.同理,乙個資料庫例項到達瓶頸,所以可能需要分庫
開始分表分庫都需要乙個依據.一般都安裝主鍵自增id來分割,很多時候分頁都是有時間排序的,這樣分割也能保證時間的排序.我接觸到的也是按照主鍵切割居多,保證了資料分布均勻,請求也相對均勻.特殊情況下,對於近期資料請求居多的,也方便處理.我們暫時假設我們是按照主鍵分割的.
第一部分 :曲線救國
實際上分頁需要的核心是乙個全域性視野.也就是說,只要能保證有乙個全域性計算的地方就可以快速分頁.這個時候我們可以維護一張"索引表":
create table table_index
主鍵id,
你要排序的字段(也可能是多個);
這樣,我們就可以根據字段進行排序,再找到對應的主鍵id.再回表.但是涉及到乙個問題是,如果分割的表很多的話,我們可能需要到多張表去查,且這個數字是不確定的,可能是所有表才查到了所需資料,也可能是一張表就查到了,那如何處理的,很自然的,我們可以為這個表再加乙個字段,標識這條資料所在的分表,然後根據查到的結果再分類查詢,整理.
弊端:需要額外的維護一張表,且這張表維護的成本並不小,比如某一張分表再此表的數值做了寫操作了.分表增加刪除的體現等
效率.考慮到要查詢到所有所需的資料既可能在一張也有可能是所有, 在資料量大分表多的情況下.logn的效率其實也不是能被接受的
這張表的大小畢竟也是有限制的
好處:畢竟邏輯簡單直接,開發成本低.
在資料分表不多的情況下,可以被接受.有張全域性表也方便做一些統計
第二部分:直接幹
1 全域性找:
其實最簡單粗暴,需要第三頁的資料,就把所有分表的前三頁資料都拿出來,利用程式做排序,然後再取真正第三頁的資料
特點:資料變多了,自然消耗各種東西,網路頻寬等,而且還要做計算.最可怕的不是第三頁,如果是三百頁,一頁一百條,那已經不是乙個量級了.計算也需要消耗更多的時間,但是資料確實是準確的
2 全域性找的折中處理
首先如果業務不需要那麼精確地分頁,那麼問題迎刃而解,比如要找第12頁的資料,假設分表是三個,那我們在三個分表中分表取四條,就是12頁的全域性資料,這樣也是極好的,只是資料不再那麼精確.
3 二次查詢
首次查詢查詢每個庫的select * from table order by time offset 10 limit 10;得到10條資料。這裡的offset是總offset/分庫數
服務層得到來自兩個分庫的結果集,得到最小的time,也就是最頂層的time，這個time滿足最少有10條記錄在它前面.然後分別記錄每個庫的最大time
分別再次查詢最小time->每個庫上一次的最大time的資料，得到每個庫的查詢結果
在每個集合的最小time都是相同的，所以可以得到該最小time在整個資料庫中的offset，加起來就是這個最小time在全域性庫的offset位置。
再將第二次查詢的結果集拼起來和得到的最小time的offset，推導出 offset 20 limit 10的一頁記錄。
弊端需要進行兩次資料庫查詢
優點可以精確得到業務資料，且每次返回的資料量都非常小，不會隨著頁碼增加而資料量增大。
mysql跨庫跨表查詢
簡單記錄 select from dysns.uchome pay record,91feile.phpcms game where uchome pay record.uid phpcms game.touserid select from dysns.uchome pay record,91fe...
跨庫跨表的分頁查詢實現
對於資料庫分庫分表之後，涉及到查詢時就會存在一些問題，比如如何分頁，如何排序，如何處理函式平均值等等，特別是對於分頁功能，需要在應用中將資料合併後進行排序，在顯示，還需要考慮應用中翻頁的頁碼與實際庫中查詢時頁碼的關係，同時還需要考慮某個庫資料查詢完畢後，其他庫中如何增加每次查詢頁碼的問題，否則查詢後...
mysql跨服務跨庫查詢
若是不同服務不同庫需要 檢視federated引擎是否開啟 mysql查詢視窗輸入指令 show engines 如果有federated引擎，但support是no，說明你的mysql安裝了這個引擎，但沒啟用，去mysql安裝錄下找到配置檔案my.ini，在 mysqld 字段 檔案末 新增一行f...