十年網(wǎng)站開發(fā)經(jīng)驗 + 多家企業(yè)客戶 + 靠譜的建站團隊
量身定制 + 運營維護+專業(yè)推廣+無憂售后,網(wǎng)站問題一站解決
當業(yè)務上按照月份分表,但是前端h5需要分頁展示,小伙伴們不知有沒有遇到這個這個需求最后怎么完成的。
網(wǎng)站制作、成都做網(wǎng)站,成都做網(wǎng)站公司-創(chuàng)新互聯(lián)已向上千多家企業(yè)提供了,網(wǎng)站設計,網(wǎng)站制作,網(wǎng)絡營銷等服務!設計與技術(shù)結(jié)合,多年網(wǎng)站推廣經(jīng)驗,合理的價格為您打造企業(yè)品質(zhì)網(wǎng)站。
我這里想了一個解決思路,可能還不完善,希望能拋轉(zhuǎn)引玉。
1、入?yún)ageNo 為頁號碼,如果為1那么就是第一頁。pageSize 可以是入?yún)⒁部啥ㄋ溃@里定死10條。Limit 是數(shù)據(jù)偏移標記,根據(jù)入?yún)ageNo 計算出來的,Limit=(pageNo-1)*pageSize。假設A表有41條數(shù)據(jù)符合,B表有51條數(shù)據(jù)符合,如下圖。
有幾種種情況? ?1.如果limitA表41條 那么需要從A表中取數(shù)據(jù),(1)如果Limit+pageSizeCount直接獲取數(shù)據(jù)即可(2)如果Limit+pageSizeCount,那么需要從A 表取部分數(shù)據(jù)從B表取一部分數(shù)據(jù)。
1.如果limitA表41條? 那么需要從B表取數(shù)據(jù),如果B數(shù)據(jù)依然不足,那么重復以上的步驟。如下圖
1.如果只是為了分頁,可以考慮這種分表,就是表的id是范圍性的,且id是連續(xù)的,比如第一張表id是1到10萬,第二張是10萬到20萬,這樣分頁應該沒什么問題。
2.如果是其他的分表方式,建議用sphinx先建索引,然后查詢分頁,我們公司現(xiàn)在就是這樣干的
mysql分庫分表一般有如下場景
其中1,2相對較容易實現(xiàn),本文重點講講水平拆表和水平拆庫,以及基于mybatis插件方式實現(xiàn)水平拆分方案落地。
在 《聊一聊擴展字段設計》 一文中有講解到基于KV水平存儲擴展字段方案,這就是非常典型的可以水平分表的場景。主表和kv表是一對N關(guān)系,隨著主表數(shù)據(jù)量增長,KV表最大N倍線性增長。
這里我們以分KV表水平拆分為場景
對于kv擴展字段查詢,只會根據(jù)id + key 或者 id 為條件的方式查詢,所以這里我們可以按照id 分片即可
分512張表(實際場景具體分多少表還得根據(jù)字段增加的頻次而定)
分表后表名為kv_000 ~ kv_511
id % 512 = 1 .... 分到 kv_001,
id % 512 = 2 .... 分到 kv_002
依次類推!
水平分表相對比較容易,后面會講到基于mybatis插件實現(xiàn)方案
場景:以下我們基于博客文章表分庫場景來分析
目標:
表結(jié)構(gòu)如下(節(jié)選部分字段):
按照user_id sharding
假如分1024個庫,按照user_id % 1024 hash
user_id % 1024 = 1 分到db_001庫
user_id % 1024 = 2 分到db_002庫
依次類推
目前是2個節(jié)點,假如后期達到瓶頸,我們可以增加至4個節(jié)點
最多可以增加只1024個節(jié)點,性能線性增長
對于水平分表/分庫后,非shardingKey查詢首先得考慮到
基于mybatis分庫分表,一般常用的一種是基于spring AOP方式, 另外一種基于mybatis插件。其實兩種方式思路差不多。
為了比較直觀解決這個問題,我分別在Executor 和StatementHandler階段2個攔截器
實現(xiàn)動態(tài)數(shù)據(jù)源獲取接口
測試結(jié)果如下
由此可知,我們需要在Executor階段 切換數(shù)據(jù)源
對于分庫:
原始sql:
目標sql:
其中定義了三個注解
@useMaster 是否強制讀主
@shardingBy 分片標識
@DB 定義邏輯表名 庫名以及分片策略
1)編寫entity
Insert
select
以上順利實現(xiàn)mysql分庫,同樣的道理實現(xiàn)同時分庫分表也很容易實現(xiàn)。
此插件具體實現(xiàn)方案已開源:
目錄如下:
mysql分庫分表,首先得找到瓶頸在哪里(IO or CPU),是分庫還是分表,分多少?不能為了分庫分表而拆分。
原則上是盡量先垂直拆分 后 水平拆分。
以上基于mybatis插件分庫分表是一種實現(xiàn)思路,還有很多不完善的地方,
例如:
1.按時間分表
這種分表方式有一定的局限性,當數(shù)據(jù)有較強的實效性,如微博發(fā)送記錄、微信消息記錄等,這種數(shù)據(jù)很少有用戶會查詢幾個月前的數(shù)據(jù),如就可以按月分表。
2.按區(qū)間范圍分表
一般在有嚴格的自增id需求上,如按照user_id水平分表:
table_1 ?user_id從1~100w?
table_2 ?user_id從101~200w?
table_3 ?user_id從201~300w?
...?
3.hash分表
通過一個原始目標的ID或者名稱通過一定的hash算法計算出數(shù)據(jù)存儲表的表名,然后訪問相應的表。
按如下分10張表:
function?get_hash_table($table,?$userid)
{
$str?=?crc32($userid);
if?($str??0)?{
$hash?=?"0"?.?substr(abs($str),?0,?1);
}?else?{
$hash?=?substr($str,?0,?2);
}
return?$table?.?"_"?.?$hash;
}
echo get_hash_table('message',?'user18991');?//結(jié)果為message_10
echo get_hash_table('message',?'user34523');?//結(jié)果為message_13