分表是分散資料庫壓力的好方法。
分表，最直白的意思，就是將一個表結構分為多個表，然後，可以再同一個庫里，也可以放到不同的庫。
當然，首先要知道什麼情況下，才需要分表。個人覺得單表記錄條數達到百萬到千萬級別時就要使用分表了。
分表的分類
**1、縱向分表**
將本來可以在同一個表的內容，人為劃分為多個表。（所謂的本來，是指按照關系型資料庫的第三範式要求，是應該在同一個表的。）
分表理由：根據數據的活躍度進行分離，（因為不同活躍的數據，處理方式是不同的）
案例：
對於一個博客系統，文章標題，作者，分類，創建時間等，是變化頻率慢，查詢次數多，而且最好有很好的實時性的數據，我們把它叫做冷數據。而博客的瀏覽量，回復數等，類似的統計信息，或者別的變化頻率比較高的數據，我們把它叫做活躍數據。所以，在進行資料庫結構設計的時候，就應該考慮分表，首先是縱向分表的處理。
這樣縱向分表後：
首先存儲引擎的使用不同，冷數據使用MyIsam 可以有更好的查詢數據。活躍數據，可以使用Innodb ,可以有更好的更新速度。
其次，對冷數據進行更多的從庫配置，因為更多的操作時查詢，這樣來加快查詢速度。對熱數據，可以相對有更多的主庫的橫向分表處理。
其實，對於一些特殊的活躍數據，也可以考慮使用memcache ,redis之類的緩存，等累計到一定量再去更新資料庫。或者mongodb 一類的nosql 資料庫，這里只是舉例，就先不說這個。
**2、橫向分表**
字面意思，就可以看出來，是把大的表結構，橫向切割為同樣結構的不同表，如，用戶信息表，user_1,user_2等。表結構是完全一樣，但是，根據某些特定的規則來劃分的表，如根據用戶ID來取模劃分。
分表理由：根據數據量的規模來劃分，保證單表的容量不會太大，從而來保證單表的查詢等處理能力。
案例：同上面的例子，博客系統。當博客的量達到很大時候，就應該採取橫向分割來降低每個單表的壓力，來提升性能。例如博客的冷數據表，假如分為100個表，當同時有100萬個用戶在瀏覽時，如果是單表的話，會進行100萬次請求，而現在分表後，就可能是每個表進行1萬個數據的請求（因為，不可能絕對的平均，只是假設），這樣壓力就降低了很多很多。
延伸：為什麼要分表和分區？
日常開發中我們經常會遇到大表的情況，所謂的大表是指存儲了百萬級乃至千萬級條記錄的表。這樣的表過於龐大，導致資料庫在查詢和插入的時候耗時太長，性能低下，如果涉及聯合查詢的情況，性能會更加糟糕。分表和表分區的目的就是減少資料庫的負擔，提高資料庫的效率，通常點來講就是提高表的增刪改查效率。
什麼是分表？
分表是將一個大表按照一定的規則分解成多張具有獨立存儲空間的實體表，我們可以稱為子表，每個表都對應三個文件，MYD數據文件，.MYI索引文件，.frm表結構文件。這些子表可以分布在同一塊磁碟上，也可以在不同的機器上。app讀寫的時候根據事先定義好的規則得到對應的子表名，然後去操作它。
什麼是分區？
分區和分表相似，都是按照規則分解表。不同在於分表將大表分解為若干個獨立的實體表，而分區是將數據分段劃分在多個位置存放，可以是同一塊磁碟也可以在不同的機器。分區後，表面上還是一張表，但數據散列到多個位置了。app讀寫的時候操作的還是大表名字，db自動去組織分區的數據。
**MySQL分表和分區有什麼聯系呢？**
1、都能提高mysql的性高，在高並發狀態下都有一個良好的表現。
2、分表和分區不矛盾，可以相互配合的，對於那些大訪問量，並且表數據比較多的表，我們可以採取分表和分區結合的方式（如果merge這種分表方式，不能和分區配合的話，可以用其他的分表試），訪問量不大，但是表數據很多的表，我們可以採取分區的方式等。
3、分表技術是比較麻煩的，需要手動去創建子表，app服務端讀寫時候需要計運算元表名。採用merge好一些，但也要創建子表和配置子表間的union關系。
4、表分區相對於分表，操作方便，不需要創建子表。
我們知道對於大型的互聯網應用，資料庫單表的數據量可能達到千萬甚至上億級別，同時面臨這高並發的壓力。Master-Slave結構只能對資料庫的讀能力進行擴展，寫操作還是集中在Master中，Master並不能無限制的掛接Slave庫，如果需要對資料庫的吞吐能力進行進一步的擴展，可以考慮採用分庫分表的策略。
**1、分表**
在分表之前，首先要選中合適的分表策略（以哪個字典為分表欄位，需要將數據分為多少張表），使數據能夠均衡的分布在多張表中，並且不影響正常的查詢。在企業級應用中，往往使用org_id(組織主鍵)做為分表欄位，在互聯網應用中往往是userid。在確定分表策略後，當數據進行存儲及查詢時，需要確定到哪張表裡去查找數據，
數據存放的數據表 = 分表欄位的內容 % 分表數量
**2、分庫**
分表能夠解決單表數據量過大帶來的查詢效率下降的問題，但是不能給資料庫的並發訪問帶來質的提升，面對高並發的寫訪問，當Master無法承擔高並發的寫入請求時，不管如何擴展Slave伺服器，都沒有意義了。我們通過對資料庫進行拆分，來提高資料庫的寫入能力，即所謂的分庫。分庫採用對關鍵字取模的方式，對資料庫進行路由。
數據存放的資料庫=分庫欄位的內容%資料庫的數量
**3、即分表又分庫**
資料庫分表可以解決單表海量數據的查詢性能問題，分庫可以解決單台資料庫的並發訪問壓力問題。
當資料庫同時面臨海量數據存儲和高並發訪問的時候，需要同時採取分表和分庫策略。一般分表分庫策略如下：
中間變數 = 關鍵字%（資料庫數量*單庫數據表數量）
庫 = 取整（中間變數/單庫數據表數量）
表 = （中間變數%單庫數據表數量）
實例：
1、分庫分表
很明顯，一個主表（也就是很重要的表，例如用戶表）無限制的增長勢必嚴重影響性能，分庫與分表是一個很不錯的解決途徑，也就是性能優化途徑，現在的案例是我們有一個1000多萬條記錄的用戶表members,查詢起來非常之慢，同事的做法是將其散列到100個表中，分別從members0到members99，然後根據mid分發記錄到這些表中，牛逼的代碼大概是這樣子：
復制代碼 代碼如下:
<?php
for($i=0;$i< 100; $i++ ){
//echo "CREATE TABLE db2.members{$i} LIKE db1.members
";
echo "INSERT INTO members{$i} SELECT * FROM members WHERE mid%100={$i}
";
}
?>
2、不停機修改mysql表結構
同樣還是members表，前期設計的表結構不盡合理，隨著資料庫不斷運行，其冗餘數據也是增長巨大，同事使用了下面的方法來處理：
先創建一個臨時表：
/*創建臨時表*/
CREATE TABLE members_tmp LIKE members
然後修改members_tmp的表結構為新結構，接著使用上面那個for循環來導出數據，因為1000萬的數據一次性導出是不對的，mid是主鍵，一個區間一個區間的導，基本是一次導出5萬條吧，這里略去了
接著重命名將新表替換上去：
/*這是個頗為經典的語句哈*/
RENAME TABLE members TO members_bak,members_tmp TO members;
就是這樣，基本可以做到無損失，無需停機更新表結構，但實際上RENAME期間表是被鎖死的，所以選擇在線少的時候操作是一個技巧。經過這個操作，使得原先8G多的表，一下子變成了2G多。
Ⅱ MySQL分區表簡介
我們的業務只存近一段時間的數據，因此有大量表需要清理 歷史 數據，目前使用的delete清理數據，存在以下問題。為避免同時支持大量delete，我們的清理任務只在低峰期串列執行，導致任務過多時需要排隊，甚至失敗的情況；數據清理使用delete語句，表數據量較大時，對資料庫造成很大壓力；即使我們刪除了舊數據，已刪除的數據仍占據存儲空間，底層數據文件並沒有立刻變小，以至於形成數據空洞。
查看MySQL官方文檔時，發現了分區表，因此基於官方文檔總結一下。
MySQL邏輯上為一個表，物理上存儲在多個文件中，這是 MySQL 支持的功能（5.1 開始）, 8.0 版本只 InnoDB 和 NDB 支持分區表。
優點：
缺點：
根據分區表鍵值的范圍把數據存儲到表的不同分區中，適用於以時間或日期作為分區類型，方便數據清理。
小提示：
1.當插入數據分區不存在時會報錯：Table has no partition for value xxx;
2.Range類型分區欄位必須是數值，時間類型可用函數轉換為數值；
3.分區欄位列值可以為null，所有為null的數據將存在最小的分區中；
按分區鍵取值的列表進行分區，每一行數據須找到對應的分區列表，否則數據插入失敗
小提示：
根據指定分區表達式的整數值以及分區數進行數據劃分(mod函數)
小提示：
按鍵分區類似於按哈希分區，只是哈希分區使用用戶定義的表達式，用於鍵分區的哈希函數由 MySQL 伺服器提供。NDB 集群為此使用 MD5() ; 對於使用其他存儲引擎的表，伺服器使用自己的內部哈希函數。
小提示：
子分區(subpartitioning)也稱為復合分區(composite partitioning) ，是已分區表中每個分區的進一步劃分
小提示：
小提示：
Ⅲ Mysql表分區狀態查詢
一、查詢mysql表是否為分區表：可以查看錶具有哪幾個分區、分區的方法、分區中數據的記錄數等信息
SELECT PARTITION_NAME,PARTITION_METHOD,PARTITION_EXPRESSION,PARTITION_DESCRIPTION,TABLE_ROWS,SUBPARTITION_NAME,SUBPARTITION_METHOD,SUBPARTITION_EXPRESSION
FROM information_schema.PARTITIONS WHERE TABLE_SCHEMA=SCHEMA() AND TABLE_NAME='xw_coobill_order';
二、查詢表有多少個分區
SELECT TABLE_NAME, COUNT(*) AS CNT
FROM information_schema.PARTITIONS WHERE PARTITION_NAME IS NOT NULL
GROUP BY TABLE_NAME ORDER BY CNT DESC LIMIT 50;
三、分析執行語句
explain partitions select * from range_datetime where hiredate >= '20151207124503' and hiredate<='20151210111230';
四、分區管理
常規HASH和線性HASH的增加收縮分區的原理是一樣的。增加和收縮分區後原來的數據會根據現有的分區數量重新分布。HASH分區不能刪除分區，所以不能使用DROP PARTITION操作進行分區刪除操作；
只能通過ALTER TABLE ... COALESCE PARTITION num來合並分區，這里的num是減去的分區數量；
可以通過ALTER TABLE ... ADD PARTITION PARTITIONS num來增加分區，這里是null是在原先基礎上再增加的分區數量。
Ⅳ 十、MySQL表分區
表分區是將⼀個表的數據按照⼀定的規則⽔平劃分為不同的邏輯塊，並分別進⾏物理存儲，這個規則就叫做分區函數，可以有不同的分區規則。5.7可以通過show plugins語句查看當前MySQL是否⽀持表分區功能。
但當表中含有主鍵或唯⼀鍵時，則每個被⽤作 分區函數的欄位必須是表中唯⼀鍵和主鍵的全部或⼀部分 ，否則就⽆法創建分區表。⽐如下⾯的表由於唯⼀鍵和主鍵沒有相同的欄位，所以⽆法創建表分區
上述例⼦中刪除唯⼀鍵，確保主鍵中的欄位包含分區函數中的所有欄位，創建成功
或者將主鍵擴展為包含ref欄位
表分區的主要優勢在於：
可以允許在⼀個表⾥存儲更多的數據，突破磁碟限制或者⽂件系統限制
對於從表⾥將過期或歷史的數據移除在表分區很容易實現，只要將對應的分區移除即可
對某些查詢和修改語句來說，可以 ⾃動 將數據范圍縮⼩到⼀個或⼏個表分區上，優化語句執⾏效率。⽽且可以通過 顯示指定表分區 來執⾏語句，⽐如 SELECT * FROM t PARTITION (p0,p1) WHERE c < 5
表分區類型分為：
范圍表分區，按照⼀定的范圍值來確定每個分區包含的數據，分區函數使⽤的欄位必須只能是 整數類型，分區的定義范圍必須是連續的，且不能有重疊部分，通過使⽤VALUES LESS THAN來定義分區范圍，表分區的范圍定義是從⼩到⼤定義的
⽐如：
Store_id<6的數據被放在p0分區⾥，6<=store_id<10之間的數據被放在p1分區⾥，以此類推，當新插⼊的數據為(72, 『Mitchell』, 『Wilson』, 『1998-06-25』, NULL, 13) 時，則新數據被插⼊到p2分區⾥，但當插⼊的數據的store_id為21時，由於沒有分區去容納此數據，所以會報錯，我們需要修改⼀下表的定義
報錯：
修改表的定義：
MAXVALUE關鍵詞的作⽤是表示可能的最⼤值，所以任何store_id>=16的數據都會被寫⼊到p3分區⾥。分區函數中也可以使⽤表達式 ，⽐如：
對timestamp欄位類型可以使⽤的表達式⽬前僅有unix_timestamp ，其他的表達式都不允許
列表表分區，按照⼀個⼀個確定的值來確定每個分區包含的數據，通過PARTITION BY LIST(expr)分區函數表達式必須返回整數，取值范圍通過VALUES IN (value_list)定義
對List表分區來說，沒有MAXVALUE特殊值，所有的可能取值都需要再VALUES IN中包含，如果有未定義的取值則會報錯
同樣，當有主鍵或者唯⼀鍵存在的情況下，分區函數欄位需要包含在主鍵或唯⼀鍵中
對range和list表分區來說，分區函數可以包含多個欄位，分區多欄位函數(column partition) 所涉及的欄位類型可以包括：
范圍多欄位分區函數與普通的范圍分區函數的區別在於：
a) 欄位類型多樣化
b) 范圍多欄位分區函數 不⽀持表達式，只能⽤欄位名
c) 范圍多欄位分區函數⽀持⼀個或多個欄位
再⽐如創建如下的表分區：
對多列對⽐來說：
當然只要保證取值范圍是增⻓的，表分區就能創建成功，⽐如：
但如果 取值范圍不是增⻓的，就會返回錯誤 ：
對其他數據類型的⽀持：
list列表多欄位表分區，例如：你有一個在12個城市客戶的業務, 為了銷售和市場的目的, 你的組織每3個城市劃分為一個區域針對LIST COLUMNS分區, 你可以基於城市的名稱創建一個客戶數據表並聲明4個分區當你的客戶在對應的這個區域:
使用日期分區
但是這種情況在日期增長到非常大的時候是很復雜的, 所以這種還是使用RANGE 分區方式比較好
按照⼀個⾃定義的函數返回值來確定每個分區包含的數據，這個 ⾃定義函數也可以僅僅是⼀個欄位名字
通過PARTITION BY HASH (expr)⼦句來表達哈希表分區，其中的 expr表達式必須返回⼀個整數，基於分區個數的取模（%）運算。根據余數插⼊到指定的分區
對哈希表分區來說只需要定義分區的個數，其他的事情由內部完成
如果沒有寫明PARTITIONS欄位，則默認為1，表達式可以是整數類型欄位，也可以是⼀個函數，⽐如
⽐如： CREATE TABLE t1 (col1 INT, col2 CHAR(5), col3 DATE) PARTITION BY HASH( YEAR(col3) ) PARTITIONS 4;
如果插⼊⼀條數據對應的col3為『2005-09-15』時，則插⼊數據的分區計算⽅法為：
與哈希表分區類似，只不過哈希表分區依賴於⾃定義的函數，⽽key表分區的哈希演算法是依賴MySQL本身， CREATE TABLE ... PARTITION BY KEY () 創建key表分區， 括弧⾥⾯可以包含0個或者多個欄位，所引⽤的欄位必須是主鍵或者主鍵的⼀部分 ，如果括弧⾥⾯沒有欄位，則代表使⽤主鍵
如果表中沒有主鍵但有唯⼀鍵，則使⽤唯⼀鍵，但 唯⼀鍵欄位必須定義為not null ，否則報錯
所引⽤的欄位未必必須是整數類型，其他的類型也可以使⽤，⽐如：
⼦表分區，是在表分區的基礎上再創建表分區的概念， 每個表分區下的⼦表分區個數必須⼀致 ，⽐如：
ts表擁有三個范圍分區，同時每個分區都各⾃有兩個⼦分區，所以總共有6個分區
⼦表分區必須是范圍/列表分區+哈希/key⼦表分區的組合
⼦表分區也可以顯示的指定⼦表分區的名字，⽐如：
不同的表分區對NULL值的處理⽅式不同
對范圍表分區來說，如果插⼊的是NULL值，則將數據放到最⼩的分區表⾥
對list表分區來說，⽀持NULL值的唯⼀情況就是某個分區的允許值中包含NULL
對哈希表分區和Key表分區來說，NULL值會被當成0值對待
通過alter table命令可以執⾏增加，刪除，重新定義，合並或者拆分表分區的管理動作
對范圍表分區和列表表分區來說，刪除⼀個表分區命令如下：
刪除表分區的動作不光會把分區刪掉，也會把表分區⾥原來的數據給刪除掉
在原分區上增加⼀個表分區可以通過alter table … add partition語句來完成
但對范圍表分區來說，增加的表分區必須在尾部增加，在頭部或者在中間增加都會失敗：
為解決這個問題，可以使⽤ REORGANIZE 命令：
對列表表分區來說，只要新增加的分區對應的值在之前的表分區中沒有出現過，就可以通過alter table… add partition來增加
當然， 也可以通過REORGANIZE命令將之前的多個分區合並成⼀個或⼏個分區，但要保持分區值⼀致：
更復雜的⽐如將多個分區重組成多個分區：
Ⅳ mysql分表的3種方法介紹，什麼是分區
可以看mysql的data文件夾下面的資料庫文件，就可以查看當前分區情況。還有幾種獲取MySQL分區表信息的常用方法SHOW CREATE TABLE 可以查看創建分區表的CREATE語句 SHOW TABLE STATUS 可以查看錶是否為分區表 查看INFORMATION_SCHEMA.PARTITIONS表 可以查看錶具有哪幾個分區、分區的方法、分區中數據的記錄數等重要信息
Ⅵ MySQL-分區表
對底層表的封裝，意味著索引也是按照分區的子表定義的，而沒有全局索引。（所以即使有唯一性索引，在不同子表中可能會有重復數據）
單表數據量超大時索引失效
將單表分區成數個區域，通過分區函數，可以快速地定位到數據的區域。而且相比於索引，分區不需要額外的數據結構記錄每個分區的數據，代價更低。只需要一個簡單的表達式就可以指向正確的分區
可以只是用簡單的分區方式存放表，不要任何索引，只要將查詢定位到需要的大致數據位置，通過where條件，將需要的數據限制在少數分區中，則效率是很高的。WARNNING：查詢需要掃描的分區個數限制在一個很小的數量。
如果數據有明顯的「熱點」，可以將熱點數據單獨放在一個分區，讓這個分區的數據能夠有機會都緩存在內存中。
如果分區表達式的值可以是NULL：第一個分區會使一個特殊分區。以partition by range year(order_date)為例，所有在order_date列為NULL或者非法值的數據都會被放到第一個分區。那麼所有的查詢在定位分區後都會增加掃描第一個分區。而且如果第一個分區很大的時候，查詢的成本會被這個「拖油瓶」分區無情的增加。
創建一個無用的第一分區可以解決這個問題，partition p_nulls values less than (0);
對於分區列和索引列不匹配的查詢，雖然查詢能夠使用索引，但是無法通過分區定位到目標數據的分區（也就是數據分布相對更加分散）,需要遍歷每個分區內的索引，除非查詢中的條件同時也包含分區條件。所以期望分區條件范圍被熱門查詢索引所包含。
對於 范圍分區 技術，需要適當限制分區的數量，否則對於大量數據批量導入的場景，選擇分區的成本過高。對於大多數系統，100個左右的分區是沒有問題的。
Ⅶ Mysql分表和分區的區別，分庫和分表區別
分表和分區的區別：
一、什麼是mysql分表，分區
分表：從表面意思上看呢，就是把一張表分成N多個小表，具體請看:mysql分表的3種方法
分區：分區呢就是把一張表的數據分成N多個區塊，這些區塊可以在同一個磁碟上，也可以在不同的磁碟上，具體請參考mysql分區功能詳細介紹，以及實例
二、mysql分表和分區有什麼區別呢
1、實現方式上
①mysql的分表是真正的分表，一張表分成很多表後，每一個小表都是完正的一張表，都對應三個文件，一個.MYD數據文件，.MYI索引文件，.frm表結構文件。
[root@BlackGhosttest]#ls|grepuser
alluser.MRG
alluser.frm
user1.MYD
user1.MYI
user1.frm
user2.MYD
user2.MYI
user2.frm
簡單說明一下，上面的分表呢是利用了merge存儲引擎（分表的一種），alluser是總表，下面有二個分表，user1，user2。他們二個都是獨立的表，取數據的時候，我們可以通過總表來取。這里總表是沒有.MYD,.MYI這二個文件的，也就是說，總表他不是一張表，沒有數據，數據都放在分表裡面。我們來看看.MRG到底是什麼東西
[root@BlackGhosttest]#catalluser.MRG|more
user1
user2
#INSERT_METHOD=LAST
從上面我們可以看出，alluser.MRG裡面就存了一些分表的關系，以及插入數據的方式。可以把總表理解成一個外殼，或者是聯接池。
②分區不一樣，一張大表進行分區後，他還是一張表，不會變成二張表，但是他存放數據的區塊變多了。
[root@BlackGhosttest]#ls|grepaa
aa#P#p1.MYD
aa#P#p1.MYI
aa#P#p3.MYD
aa#P#p3.MYI
aa.frm
aa.par
從上面我們可以看出，aa這張表，分為二個區，p1和p3，本來是三個區，被我刪了一個區。我們都知道一張表對應三個文件.MYD,.MYI,.frm。分 區呢根據一定的規則把數據文件和索引文件進行了分割，還多出了一個.par文件，打開.par文件後你可以看出他記錄了，這張表的分區信息，根分表中的.MRG有點像。分區後，還是一張，而不是多張表。
如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
按照時間分區。大部分只查詢最近的訂單數據，那麼大部分只訪問一個分區，比整個表小多了，資料庫可以更加好的緩存，性能也提高了。這個是資料庫分的，應用程序透明，無需修改。
2，數據處理上
①、分表後，數據都是存放在分表裡，總表只是一個外殼，存取數據發生在一個一個的分表裡面。看下面的例子：
select * from alluser where id='12'表面上看，是對表alluser進行操作的，其實不是的。是對alluser裡面的分表進行了操作。
②、分區呢，不存在分表的概念，分區只不過把存放數據的文件分成了許多小塊，分區後的表呢，還是一張表。數據處理還是由自己來完成。
3、提高性能上
①、分表後，單表的並發能力提高了，磁碟I/O性能也提高了。並發能力為什麼提高了呢，因為查尋一次所花的時間變短了，如果出現高並發的話，總表可以根據不同 的查詢，將並發壓力分到不同的小表裡面。磁碟I/O性能怎麼搞高了呢，本來一個非常大的.MYD文件現在也分攤到各個小表的.MYD中去了。
②、mysql提出了分區的概念，我覺得就想突破磁碟I/O瓶頸，想提高磁碟的讀寫能力，來增加mysql性能。
在這一點上，分區和分表的測重點不同，分表重點是存取數據時，如何提高mysql並發能力上；而分區呢，如何突破磁碟的讀寫能力，從而達到提高mysql性能的目的。
4、實現的難易度上
①、分表的方法有很多，用merge來分表，是最簡單的一種方式。這種方式根分區難易度差不多，並且對程序代碼來說可以做到透明的。如果是用其他分表方式就比分區麻煩了。
②、分區實現是比較簡單的，建立分區表，根建平常的表沒什麼區別，並且對開代碼端來說是透明的。
三、mysql分表和分區有什麼聯系呢
1、都能提高mysql的性高，在高並發狀態下都有一個良好的表面。
2、分表和分區不矛盾，可以相互配合的，對於那些大訪問量，並且表數據比較多的表，我們可以採取分表和分區結合的方式（如果merge這種分表方式，不能和分區配合的話，可以用其他的分表試），訪問量不大，但是表數據很多的表，我們可以採取分區的方式等。
分庫分表區別：
1、什麼是分庫分表？
從字面上簡單理解，就是把原本存儲於一個庫的數據分塊存儲到多個庫上，把原本存儲於一個表的數據分塊存儲到多個表上。
2、為什麼要分庫分表？
資料庫中的數據量不一定是可控的，在未進行分庫分表的情況下，隨著時間和業務的發展，庫中的表會越來越多，表中的數據量也會越來越大，相應地，數據操作，增刪改查的開銷也會越來越大；另外，一台伺服器的資源（CPU、磁碟、內存、IO等）是有限的，最終資料庫所能承載的數據量、數據處理能力都將遭遇瓶頸,。
3、分庫分表的實施策略。
如果你的單機性能很低了，那可以嘗試分庫。分庫，業務透明，在物理實現上分成多個伺服器，不同的分庫在不同伺服器上。分區可以把表分到不同的硬碟上，但不能分配到不同伺服器上。一台機器的性能是有限制的，用分庫可以解決單台伺服器性能不夠，或者成本過高問題。
當分區之後，表還是很大，處理不過來，這時候可以用分庫。
orderid,userid,ordertime,.....
userid%4=0，用分庫1
userid%4=1，用分庫2
userid%4=2, 用分庫3
userid%4=3，用分庫4
上面這個就是一個簡單的分庫路由，根據userid選擇分庫，即不同的伺服器
分庫分表有垂直切分和水平切分兩種。
3.1、何謂垂直切分，即將表按照功能模塊、關系密切程度劃分出來，部署到不同的庫上。例如，我們會建立定義資料庫workDB、商品資料庫payDB、用戶資料庫userDB、日誌資料庫logDB等，分別用於存儲項目數據定義表、商品定義表、用戶數據表、日誌數據表等。
如userid,name,addr一個表，為了防止表過大，分成2個表。
userid,name
userid,addr
3.2、何謂水平切分，當一個表中的數據量過大時，我們可以把該表的數據按照某種規則，例如userID散列、按性別、按省，進行劃分，然後存儲到多個結構相同的表，和不同的庫上。
例如，我們的userDB中的用戶數據表中，每一個表的數據量都很大，就可以把userDB切分為結構相同的多個userDB：part0DB、part1DB等，再將userDB上的用戶數據表userTable，切分為很多userTable：userTable0、userTable1等，然後將這些表按照一定的規則存儲到多個userDB上。
3.3、應該使用哪一種方式來實施資料庫分庫分表，這要看資料庫中數據量的瓶頸所在，並綜合項目的業務類型進行考慮。
如果資料庫是因為表太多而造成海量數據，並且項目的各項業務邏輯劃分清晰、低耦合，那麼規則簡單明了、容易實施的垂直切分必是首選。
而如果資料庫中的表並不多，但單表的數據量很大、或數據熱度很高，這種情況之下就應該選擇水平切分，水平切分比垂直切分要復雜一些，它將原本邏輯上屬於一體的數據進行了物理分割，除了在分割時要對分割的粒度做好評估，考慮數據平均和負載平均，後期也將對項目人員及應用程序產生額外的數據管理負擔。
在現實項目中，往往是這兩種情況兼而有之，這就需要做出權衡，甚至既需要垂直切分，又需要水平切分。我們的游戲項目便綜合使用了垂直與水平切分，我們首先對資料庫進行垂直切分，然後，再針對一部分表，通常是用戶數據表，進行水平切分。
4 分庫分表存在的問題。
4.1 事務問題。
在執行分庫分表之後，由於數據存儲到了不同的庫上，資料庫事務管理出現了困難。如果依賴資料庫本身的分布式事務管理功能去執行事務，將付出高昂的性能代價；如果由應用程序去協助控制，形成程序邏輯上的事務，又會造成編程方面的負擔。
4.2 跨庫跨表的join問題。
在執行了分庫分表之後，難以避免會將原本邏輯關聯性很強的數據劃分到不同的表、不同的庫上，這時，表的關聯操作將受到限制，我們無法join位於不同分庫的表，也無法join分表粒度不同的表，結果原本一次查詢能夠完成的業務，可能需要多次查詢才能完成。
4.3 額外的數據管理負擔和數據運算壓力。
額外的數據管理負擔，最顯而易見的就是數據的定位問題和數據的增刪改查的重復執行問題，這些都可以通過應用程序解決，但必然引起額外的邏輯運算，例如，對於一個記錄用戶成績的用戶數據表userTable，業務要求查出成績最好的100位，在進行分表之前，只需一個order by語句就可以搞定，但是在進行分表之後，將需要n個order by語句，分別查出每一個分表的前100名用戶數據，然後再對這些數據進行合並計算，才能得出結果。