MySQL 分割槽分庫分表簡介
阿新 • • 發佈：2018-12-24
1.Mysql分割槽：
(1) 是什麼:如一張表的資料量太大，那麼myd,myi就會變的很大，查詢資料就會變的很慢，這個時候我們可以利用mysql的分割槽功能，在物理上將這一張表對應的三個檔案，分割成許多個小塊，這樣呢，我們查詢一條資料時，就不用全部查找了，只要知道這條資料在哪一塊，然後在那一塊找就行了，如果表的資料太大，可能一個磁碟放不下，這個時候，就可以把資料分配到不同的磁盤裡面去。
(2) 能幹嘛：
①邏輯資料分割；
②提高單一的寫和讀應用速度；
③提高分割槽範圍讀查詢的速度；
④分割資料能夠有多個不同的物理檔案路徑；
檢視分割槽 2 次
②List分割槽：
原理：MySQL中的LIST分割槽在很多方面類似於RANGE分割槽。和按照RANGE分割槽一樣，每個分割槽必須明確定義。它們的主要區別在於，LIST分割槽中每個分割槽的定義和選擇是基於某列的值從屬於一個值列表集中的一個值。而RANGE分割槽是從屬於一個連續區間值的集合。
案例SQL(建表);
create table area(
id INT NOT NULL PRIMARY KEY,
region varchar(20)
)engine myisam charset utf8;
insert into area values(1,'bj');
insert into area values(2,'sh');
insert into area values(3,'gz');
insert into area values(4,'sz');
create table user (
uid int not null,
userName varchar(20),
area_id int
)engine myisam charset utf8
partition by list(area_id) (
partition bj values in (1),
partition sh values in (2),
partition gz values in (3),
partition sz values in (4)
);
insert into user(uid,userName,area_id) values(1,'z3',1);
insert into user(uid,userName,area_id) values(2,'z4',2);
insert into user(uid,userName,area_id) values(3,'z5',3);
案例SQL( 案例SQL):
③其它：Hash分割槽，Key分割槽，子分割槽。
④對NULL值的處理：
MySQL中的分割槽在禁止空值NULL上沒有進行處理，無論它是一個列值還是一個使用者定義表示式的值，
一般而言，在這種情況下MySQL把NULL當做零。如果你不希望出現類似情況，建議在設計表時宣告該列“NOT NULL”。
2.Mysql分庫：
(1)是什麼: 一個庫裡表太多了，導致了海量資料，系統性能下降，把原本儲存於一個庫的表拆分儲存到多個庫上，通常是將表按照功能模組、關係密切程度劃分出來，部署到不同庫上。
(2)為什麼要分庫
資料庫叢集環境後都是多臺slave,基本滿足了讀取操作;但是寫入或者說大資料、頻繁的寫入操作對master(主人：這裡指Mysql資料庫)效能影響就比較大，這個時候，單庫並不能解決大規模併發寫入的問題。
優點: ①減少增量資料寫入時的鎖對查詢的影響。
②由於單表數量下降，常見的查詢操作由於減少了需要掃描的記錄，使得單表單次查詢所需的檢索行數變少，減少了磁碟IO，時延變短。
缺點：無法解決單表資料量太大的問題。
3.Mysql分表：
(1)是什麼:
①垂直拆分:user_main,user_job,user_contact.
通常是按照業務功能的使用頻次，把主要的、熱門的欄位放在一起做為主要表；
然後把不常用的，按照各自的業務屬性進行聚集，拆分到不同的次要表中；主要表和次要表的關係一般都是一對一的。
②水平拆分(資料分片):mysql單表的容量不超過300-500W，否則不建議水平拆分
(2)能幹嘛:
(3)怎麼玩:
①切分策略
②導航路由
③是否有一些開源方案:MySQL Fabric,Atlas,TDDL,MySQL proxy
4.小總結：
(1)分庫分表演變過程:
單庫多表--->讀寫分離主從複製--->垂直分庫，每個庫又可以帶著salve--->繼續垂直分庫，極端情況單庫單表--->分割槽(變相的水平拆分表，只不過是單庫的)--->水平分表後，再放入多個數據庫裡，進行分散式部署，終極method。
(2)分庫分表後的難題:
①分散式事務的問題，資料的完整性和一致性問題。
②資料操作維度問題：使用者、交易、訂單各個不同的維度，使用者查詢維度、產品資料分析維度的不同對比分析角度。
③跨庫聯合查詢的問題，可能需要兩次查詢
④跨節點的count、order by、group by以及聚合函式問題，可能需要分別在各個節點上得到結果後在應用程式端進行合併
⑤額外的資料管理負擔，如：訪問資料表的導航定位
⑥額外的資料運算壓力，如：需要在多個節點執行，然後再合併計算
⑦程式編碼開發難度提升，沒有太好的框架解決，更多依賴業務看如何分，如何合，是個難題。
(3)不到最後一步，輕易不用進行水平分表.
5.我的理解：
分割槽：:如一張表的資料量太大，查詢資料就會變的很慢，這個時候我們可以利用mysql的分割槽功能，在物理上將這一張表對應的三個檔案(.MYD資料檔案，.MYI索引檔案，.frm表結構檔案 )，分割成許多個小塊，這樣呢，我們查詢一條資料時，就不用全部查找了，只要知道這條資料在哪一塊，然後在那一塊找就行了，如果表的資料太大，可能一個磁碟放不下，這個時候，就可以把資料分配到不同的磁盤裡面去。再一般情況下我們分為12個區。
分庫： 一個庫裡表太多了，導致了海量資料，系統性能下降，把原本儲存於一個庫的表拆分儲存到多個庫上，通常是將表按照功能模組、關係密切程度劃分出來，部署到不同庫上。
分表：一個表中的資料太大，可以分為水平拆分 和 垂直拆分: