地址：https://www.cnblogs.com/langtianya/p/4997768.html

分表和分區(qū)的區(qū)別：

一，什么是mysql分表，分區(qū)

什么是分表，從表面意思上看呢，就是把一張表分成N多個小表，具體請看:mysql分表的3種方法

什么是分區(qū)，分區(qū)呢就是把一張表的數(shù)據(jù)分成N多個區(qū)塊，這些區(qū)塊可以在同一個磁盤上，也可以在不同的磁盤上，具體請參考mysql分區(qū)功能詳細介紹，以及實例

二，mysql分表和分區(qū)有什么區(qū)別呢

1，實現(xiàn)方式上

a），mysql的分表是真正的分表，一張表分成很多表后，每一個小表都是完正的一張表，都對應三個文件，一個.MYD數(shù)據(jù)文件，.MYI索引文件，.frm表結構文件。

Sql代碼

[root@BlackGhost test]# ls |grep user?

alluser.MRG?

alluser.frm?

user1.MYD?

user1.MYI?

user1.frm?

user2.MYD?

user2.MYI?

user2.frm ?

簡 單說明一下，上面的分表呢是利用了merge存儲引擎（分表的一種），alluser是總表，下面有二個分表，user1，user2。他們二個都是獨立 的表，取數(shù)據(jù)的時候，我們可以通過總表來取。這里總表是沒有.MYD,.MYI這二個文件的，也就是說，總表他不是一張表，沒有數(shù)據(jù)，數(shù)據(jù)都放在分表里面。我們來看看.MRG到底是什么東西

Sql代碼

[root@BlackGhost test]# cat?

alluser.MRG |more user1 user2

#INSERT_METHOD=LAST

從上面我們可以看出，alluser.MRG里面就存了一些分表的關系，以及插入數(shù)據(jù)的方式?？梢园芽偙砝斫獬梢粋€外殼，或者是聯(lián)接池。

b），分區(qū)不一樣，一張大表進行分區(qū)后，他還是一張表，不會變成二張表，但是他存放數(shù)據(jù)的區(qū)塊變多了。

Sql代碼

[root@BlackGhost test]# ls |grep aa?

aa#P#p1.MYD?

aa#P#p1.MYI?

aa#P#p3.MYD?

aa#P#p3.MYI?

aa.frm aa.par

從 上面我們可以看出，aa這張表，分為二個區(qū)，p1和p3，本來是三個區(qū)，被我刪了一個區(qū)。我們都知道一張表對應三個文件.MYD,.MYI,.frm。分 區(qū)呢根據(jù)一定的規(guī)則把數(shù)據(jù)文件和索引文件進行了分割，還多出了一個.par文件，打開.par文件后你可以看出他記錄了，這張表的分區(qū)信息，根分表中 的.MRG有點像。分區(qū)后，還是一張，而不是多張表。
如orderid,userid,ordertime,.....
ordertime<2015-01-01 #p0
ordertime<2015-04-01 #p1
ordertime<2015-07-01 #p2
ordertime<2015-10-01 #p3
ordertime<2016-01-01 #p4
按照時間分區(qū)。大部分只查詢最近的訂單數(shù)據(jù)，那么大部分只訪問一個分區(qū)，比整個表小多了，數(shù)據(jù)庫可以更加好的緩存，性能也提高了。這個是數(shù)據(jù)庫分的，應用程序透明，無需修改。

2，數(shù)據(jù)處理上

a），分表后，數(shù)據(jù)都是存放在分表里，總表只是一個外殼，存取數(shù)據(jù)發(fā)生在一個一個的分表里面?？聪旅娴睦樱?br/>
select * from alluser where id='12'表面上看，是對表alluser進行操作的，其實不是的。是對alluser里面的分表進行了操作。

b），分區(qū)呢，不存在分表的概念，分區(qū)只不過把存放數(shù)據(jù)的文件分成了許多小塊，分區(qū)后的表呢，還是一張表。數(shù)據(jù)處理還是由自己來完成。

3，提高性能上

a）， 分表后，單表的并發(fā)能力提高了，磁盤I/O性能也提高了。并發(fā)能力為什么提高了呢，因為查尋一次所花的時間變短了，如果出現(xiàn)高并發(fā)的話，總表可以根據(jù)不同 的查詢，將并發(fā)壓力分到不同的小表里面。磁盤I/O性能怎么搞高了呢，本來一個非常大的.MYD文件現(xiàn)在也分攤到各個小表的.MYD中去了。

b），mysql提出了分區(qū)的概念，我覺得就想突破磁盤I/O瓶頸，想提高磁盤的讀寫能力，來增加mysql性能。
在這一點上，分區(qū)和分表的測重點不同，分表重點是存取數(shù)據(jù)時，如何提高mysql并發(fā)能力上；而分區(qū)呢，如何突破磁盤的讀寫能力，從而達到提高mysql性能的目的。

4），實現(xiàn)的難易度上

a），分表的方法有很多，用merge來分表，是最簡單的一種方式。這種方式根分區(qū)難易度差不多，并且對程序代碼來說可以做到透明的。如果是用其他分表方式就比分區(qū)麻煩了。

b），分區(qū)實現(xiàn)是比較簡單的，建立分區(qū)表，根建平常的表沒什么區(qū)別，并且對開代碼端來說是透明的。

三，mysql分表和分區(qū)有什么聯(lián)系呢

1，都能提高mysql的性高，在高并發(fā)狀態(tài)下都有一個良好的表面。

2，分表和分區(qū)不矛盾，可以相互配合的，對于那些大訪問量，并且表數(shù)據(jù)比較多的表，我們可以采取分表和分區(qū)結合的方式（如果merge這種分表方式，不能和分區(qū)配合的話，可以用其他的分表試），訪問量不大，但是表數(shù)據(jù)很多的表，我們可以采取分區(qū)的方式等。

?

分庫分表區(qū)別：

1 基本思想之什么是分庫分表？
從字面上簡單理解，就是把原本存儲于一個庫的數(shù)據(jù)分塊存儲到多個庫上，把原本存儲于一個表的數(shù)據(jù)分塊存儲到多個表上。

2 基本思想之為什么要分庫分表？
? ?? 數(shù)據(jù)庫中的數(shù)據(jù)量不一定是可控的，在未進行分庫分表的情況下，隨著時間和業(yè)務的發(fā)展，庫中的表會越來越多，表中的數(shù)據(jù)量也會越來越大，相應地，數(shù)據(jù)操作，增刪改查的開銷也會越來越大；另外，一臺服務器的資源（CPU、磁盤、內(nèi)存、IO等）是有限的，最終數(shù)據(jù)庫所能承載的數(shù)據(jù)量、數(shù)據(jù)處理能力都將遭遇瓶頸,。

3 分庫分表的實施策略。
? ?? 如果你的單機性能很低了，那可以嘗試分庫。分庫，業(yè)務透明，在物理實現(xiàn)上分成多個服務器，不同的分庫在不同服務器上。分區(qū)可以把表分到不同的硬盤上，但不能分配到不同服務器上。一臺機器的性能是有限制的，用分庫可以解決單臺服務器性能不夠，或者成本過高問題。
當分區(qū)之后，表還是很大，處理不過來，這時候可以用分庫。
orderid,userid,ordertime,.....
userid%4=0，用分庫1
userid%4=1，用分庫2
userid%4=2, 用分庫3
userid%4=3，用分庫4
上面這個就是一個簡單的分庫路由，根據(jù)userid選擇分庫，即不同的服務器

分庫分表有垂直切分和水平切分兩種。
???? 3.1 何謂垂直切分，即將表按照功能模塊、關系密切程度劃分出來，部署到不同的庫上。例如，我們會建立定義數(shù)據(jù)庫workDB、商品數(shù)據(jù)庫payDB、用戶數(shù)據(jù)庫userDB、日志數(shù)據(jù)庫logDB等，分別用于存儲項目數(shù)據(jù)定義表、商品定義表、用戶數(shù)據(jù)表、日志數(shù)據(jù)表等。

???

如userid,name,addr一個表，為了防止表過大，分成2個表。 userid,name userid,addr

?????? 3.2 何謂水平切分，當一個表中的數(shù)據(jù)量過大時，我們可以把該表的數(shù)據(jù)按照某種規(guī)則，例如userID散列、按性別、按省，進行劃分，然后存儲到多個結構相同的表，和不同的庫上。例如，我們的userDB中的用戶數(shù)據(jù)表中，每一個表的數(shù)據(jù)量都很大，就可以把userDB切分為結構相同的多個userDB：part0DB、part1DB等，再將userDB上的用戶數(shù)據(jù)表userTable，切分為很多userTable：userTable0、userTable1等，然后將這些表按照一定的規(guī)則存儲到多個userDB上。

????? 3.3 應該使用哪一種方式來實施數(shù)據(jù)庫分庫分表，這要看數(shù)據(jù)庫中數(shù)據(jù)量的瓶頸所在，并綜合項目的業(yè)務類型進行考慮。
如果數(shù)據(jù)庫是因為表太多而造成海量數(shù)據(jù)，并且項目的各項業(yè)務邏輯劃分清晰、低耦合，那么規(guī)則簡單明了、容易實施的垂直切分必是首選。
而如果數(shù)據(jù)庫中的表并不多，但單表的數(shù)據(jù)量很大、或數(shù)據(jù)熱度很高，這種情況之下就應該選擇水平切分，水平切分比垂直切分要復雜一些，它將原本邏輯上屬于一體的數(shù)據(jù)進行了物理分割，除了在分割時要對分割的粒度做好評估，考慮數(shù)據(jù)平均和負載平均，后期也將對項目人員及應用程序產(chǎn)生額外的數(shù)據(jù)管理負擔。
在現(xiàn)實項目中，往往是這兩種情況兼而有之，這就需要做出權衡，甚至既需要垂直切分，又需要水平切分。我們的游戲項目便綜合使用了垂直與水平切分，我們首先對數(shù)據(jù)庫進行垂直切分，然后，再針對一部分表，通常是用戶數(shù)據(jù)表，進行水平切分。

4 分庫分表存在的問題。

4.1 事務問題。
?????? 在執(zhí)行分庫分表之后，由于數(shù)據(jù)存儲到了不同的庫上，數(shù)據(jù)庫事務管理出現(xiàn)了困難。如果依賴數(shù)據(jù)庫本身的分布式事務管理功能去執(zhí)行事務，將付出高昂的性能代價；如果由應用程序去協(xié)助控制，形成程序邏輯上的事務，又會造成編程方面的負擔。

4.2 跨庫跨表的join問題。
??? 在執(zhí)行了分庫分表之后，難以避免會將原本邏輯關聯(lián)性很強的數(shù)據(jù)劃分到不同的表、不同的庫上，這時，表的關聯(lián)操作將受到限制，我們無法join位于不同分庫的表，也無法join分表粒度不同的表，結果原本一次查詢能夠完成的業(yè)務，可能需要多次查詢才能完成。

4.3 額外的數(shù)據(jù)管理負擔和數(shù)據(jù)運算壓力。
額外的數(shù)據(jù)管理負擔，最顯而易見的就是數(shù)據(jù)的定位問題和數(shù)據(jù)的增刪改查的重復執(zhí)行問題，這些都可以通過應用程序解決，但必然引起額外的邏輯運算，例如，對于一個記錄用戶成績的用戶數(shù)據(jù)表userTable，業(yè)務要求查出成績最好的100位，在進行分表之前，只需一個order by語句就可以搞定，但是在進行分表之后，將需要n個order by語句，分別查出每一個分表的前100名用戶數(shù)據(jù)，然后再對這些數(shù)據(jù)進行合并計算，才能得出結果。