給小白演示 分庫分表案例

受群里小伙伴之邀，搞一個分庫分表案例，這樣讓很多沒用過分庫分表的心里也有個底，不然永遠看到的都是網(wǎng)上的各種概念和解決方案性的文章。

青龍網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)！從網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、成都響應(yīng)式網(wǎng)站建設(shè)公司等網(wǎng)站項目制作，到程序開發(fā)，運營維護。創(chuàng)新互聯(lián)成立于2013年到現(xiàn)在10年的時間，我們擁有了豐富的建站經(jīng)驗和運維經(jīng)驗，來保證我們的工作的順利進行。專注于網(wǎng)站建設(shè)就選創(chuàng)新互聯(lián)。

由于用戶表過于龐大，采取相關(guān)SQL優(yōu)化，還是不能滿足，所以現(xiàn)對其進行做分庫分表。

數(shù)據(jù)庫： my-sharding

數(shù)據(jù)庫表： t_user

建表語句如下：

關(guān)于數(shù)據(jù)庫分庫分表通常有兩種方案：

下面我們來演示水平拆分，大致思路：

加入有2000萬條數(shù)據(jù)，那么為了方便演示，我們就暫定分為五個庫，每個數(shù)據(jù)庫對應(yīng)五個表。

五個數(shù)據(jù)庫：

每個數(shù)據(jù)庫有五張表：

建表語句如下：

使用技術(shù)棧： JDK8 + MySQL + Spring Boot + Mybatis + Shardingsphere + Druid

maven 相關(guān)依賴：

配置文件相關(guān)配置如下：

分庫分表的兩個分片類：

下面是業(yè)務(wù)部分代碼，先看 UserMapper.xml 內(nèi)容：

UserMapper 接口：

為了更好地演示，我這里加入了 controller 層和 service 層，這也是大家平常開發(fā)套路。

service 層代碼如下：

controller層代碼如下：

最后是項目的啟動類：

啟動項目，啟動成功：

下面我們來演示一下新增數(shù)據(jù)和查詢。

先來添加數(shù)據(jù)到數(shù)據(jù)庫中，這里使用的是IDEA中restful工具：

后臺日志：

再查看數(shù)據(jù)庫表中：

到此，我們的數(shù)據(jù)依舊落庫，下面我們來演示一下數(shù)據(jù)查詢。

瀏覽器里輸入：

返回數(shù)據(jù)：

后臺日志：

從日志和返回結(jié)果可以看出，已經(jīng)為我們正確的選擇到對應(yīng)的數(shù)據(jù)庫和表了，這樣，一個分庫分表的查詢就成功了。

本文沒有太多的概念，直接使用案例演示。相關(guān)概念性的文章，還有分庫分表解決方案的文章，網(wǎng)上一堆堆的，感興趣可以自行查閱。

淺談mysql數(shù)據(jù)庫分庫分表那些事-億級數(shù)據(jù)存儲方案

mysql分庫分表一般有如下場景

其中1，2相對較容易實現(xiàn),本文重點講講水平拆表和水平拆庫,以及基于mybatis插件方式實現(xiàn)水平拆分方案落地。

在 《聊一聊擴展字段設(shè)計》 一文中有講解到基于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)思路,還有很多不完善的地方,

例如:

如何實現(xiàn)mysql的分庫分表

1,接收到sql;2,把sql放到排隊隊列中 ;3,執(zhí)行sql;4,返回執(zhí)行結(jié)果。在這個執(zhí)行過程中最花時間在什么地方呢？第一，是排隊等待的時間，第二，sql的執(zhí)行時間。其實這二個是一回事，等待的同時，肯定有sql在執(zhí)行。所以我們要縮短sql的執(zhí)行時間。

mysql中有一種機制是表鎖定和行鎖定，為什么要出現(xiàn)這種機制，是為了保證數(shù)據(jù)的完整 性，我舉個例子來說吧，如果有二個sql都要修改同一張表的同一條數(shù)據(jù)，這個時候怎么辦呢，是不是二個sql都可以同時修改這條數(shù)據(jù)呢？很顯然mysql 對這種情況的處理是，一種是表鎖定（myisam存儲引擎），一個是行鎖定（innodb存儲引擎）。表鎖定表示你們都不能對這張表進行操作，必須等我對 表操作完才行。行鎖定也一樣，別的sql必須等我對這條數(shù)據(jù)操作完了，才能對這條數(shù)據(jù)進行操作。如果數(shù)據(jù)太多，一次執(zhí)行的時間太長，等待的時間就越長，這 也是我們?yōu)槭裁匆直淼脑颉?/p>

文章標題：mysql分庫分表怎么做 數(shù)據(jù)庫的分庫分表怎么做的
分享鏈接：http://www.ekvhdxd.cn/article4/dooiioe.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站制作、外貿(mào)建站、動態(tài)網(wǎng)站、微信公眾號、商城網(wǎng)站、網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)