拆表資料庫

A. 把一個大資料庫分為幾個小資料庫,有哪些方便地方法具體操作過程如何

互聯網公司普遍採用的讀寫分離，拆庫拆表的方法，
但是具體的要麼要在應用層做處理，類似淘寶早期的做法，要求應用區分後端的資料庫，
要麼就需要建立一個數據訪問層，由數據訪問層去處理後端的資料庫拆分，類似淘寶後期做法，
具體的你可以到文庫裡面搜淘寶分布式資料庫之類的文章來看。

B. 如何把多對多關系的表拆分成兩張一對多的表 資料庫

通過sqlserver2000的向導來創建多個表的視圖。這樣就是把多表組合成一張表了。 其中一張表做無謂關系圖就行了以偶那個該，你試試！

C. MySQL拆表遇到的問題：相同用戶的多條數據分布在拆前後的多個表中，需要類似GROUP BY的篩選效果~

SELECT MAX(login_time) AS login_time,user_id
FROM(
SELECT MAX(login_time) AS login_time,user_id FROM user_login_record GROUP BY user_id
UNION
SELECT MAX(login_time) AS login_time,user_id FROM user_login_record_20170101 GROUP BY user_id
UNION
SELECT MAX(login_time) AS login_time,user_id FROM user_login_record_20180101 GROUP BY user_id
)TMP GROUP BY user_id

D. 整個資料庫的dmp文件能拆分出表嗎

可以。
數據的切分（Sharding）根據其切分規則的類型，可以分為兩種切分模式。一種是按照不同的表（或Schema）來切分到不同的資料庫（主機）之上，這種切可以稱之為數據的垂直（縱向）切分，另外一種則是根據表中的數據的邏輯關系，將同一個表中的數據按照某種條件拆分到多台資料庫（主機）上面，這種切分稱之為數據的水平（橫向）切分。垂直切分一個資料庫由很多表的構成，每個表對應著不同的業務，垂直切分是指按照業務將表進行分類，分布到不同的資料庫上面，這樣也就將數據或者說壓力分擔到不同的庫上面， 垂直切分的優缺點介紹：
優點：拆分後業務清晰，拆分規則明確。系統之間整合或擴展容易。數據維護簡單。
缺點：部分業務表無法join，只能通過介面方式解決，提高了系統復雜度。受每種業務不同的限制存在單庫性能瓶頸，不易數據擴展跟性能提高。事務處理復雜。由於垂直切分是按照業務的分類將表分散到不同的庫，所以有些業務表會過於龐大，存在單庫讀寫與存儲瓶頸，所以就需要水平拆分來做解決。水平切分相對於垂直拆分，水平拆分不是將表做分類，而是按照某個欄位的某種規則來分散到多個庫之中，每個表中包含一部分數據。簡單來說，我們可以將數據的水平切分理解為是按照數據行的切分，就是將表中的某些行切分到一個資料庫，而另外的某些行又切分到其他的資料庫中，水平切分的優缺點介紹：拆分規則抽象好，join操作基本可以資料庫做。
不存在單庫大數據，高並發的性能瓶頸。應用端改造較少。提高了系統的穩定性跟負載能力。拆分規則難以抽象。分片事務一致性難以解決。數據多次擴展難度跟維護量極大。跨庫join性能較差。垂直切分和水平切分共同的特點和缺點有：引入分布式事務的問題。跨節點Join的問題。跨節點合並排序分頁問題。多數據源管理問題。

E. 淺談mysql資料庫分庫分表那些事-億級數據存儲方案

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

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

在 《聊一聊擴展欄位設計》 一文中有講解到基於KV水平存儲擴展欄位方案,這就是非常典型的可以水平分表的場景。主表和kv表是一對N關系,隨著主表數據量增長,KV表最大N倍線性增長。

這里我們以分KV表水平拆分為場景

對於kv擴展欄位查詢,只會根據id + key 或者 id 為條件的方式查詢,所以這里我們可以按照id 分片即可

分512張表(實際場景具體分多少表還得根據欄位增加的頻次而定)

分表後表名為kv_000 ~ kv_511

id % 512 = 1 .... 分到 kv_001,

id % 512 = 2 .... 分到 kv_002

依次類推!

水平分表相對比較容易,後面會講到基於mybatis插件實現方案

場景:以下我們基於博客文章表分庫場景來分析

目標:

表結構如下(節選部分欄位):

按照user_id sharding

假如分1024個庫,按照user_id % 1024 hash

user_id % 1024 = 1 分到db_001庫

user_id % 1024 = 2 分到db_002庫

依次類推

目前是2個節點,假如後期達到瓶頸,我們可以增加至4個節點

最多可以增加只1024個節點,性能線性增長

對於水平分表/分庫後,非shardingKey查詢首先得考慮到

基於mybatis分庫分表,一般常用的一種是基於spring AOP方式, 另外一種基於mybatis插件。其實兩種方式思路差不多。

為了比較直觀解決這個問題,我分別在Executor 和StatementHandler階段2個晌陵攔截器

實現動態數據源慎謹襲獲取介面

測試結果如下

由此可知,我們需要在Executor階段 切換數據源

對於分庫:

原始sql:

目標sql:

其中定義了三個註解

@useMaster 是否強制讀主

@shardingBy 分片標識

@DB 定義邏輯表名 庫名以及分片策略

1)編寫entity

Insert

select

以上順利實現mysql分庫,同樣的道理實現同時分庫分表也很容易實現。

此插件具體實現方案已開源: https://github.com/bytearch/mybatis-sharding

目錄如下:

mysql分庫分表,首先得找到瓶頸在哪裡(IO or CPU),是分庫還是分表,分多少？不能為了分庫分表而拆分。
原則上是盡量先垂直拆分 後 水平拆分。
以上基於mybatis插件分庫分表是一種實現思路,還有很多不完善的地方,
例如:

F. oracle資料庫按照一定條件把表拆分為多個表

其實不需要拆分表，分區就可以，還是原來的表名，只是將原來的表分成了若乾的分區，這樣能起到分表的效果，還不用分成很多的表。
比如你原來的表的名字是A，那麼將該表改為A1，然後從新建立一個分區表A，分區的依據是班級，也就是list分區，也就是一般意義上的列表分區表。
然後再將A1的數據插入新A表就可以了。
至於分區表的建立方式，往上很多，可以自行查找。
這樣操作查詢的語句不需要變，只是在不跨分區查詢的情況下，相當於分成了若干張表去查詢。比如查詢1班的成績，那麼就是在1班的分區內，不會有2班的問題，就相當於你用一個指頭就能解決問題，不會動用這個手一樣。
如果分表的話，那麼假設有12個班，那麼就要建立12張表，這樣的話，語句就要寫12次，冗餘太大了。