類似**網這樣的**，海量資料的儲存和訪問成為了系統設計的瓶頸問題，日益增長的業務資料，無疑對資料庫造成了相當大的負載，同時對於系統的穩定性和擴充套件性提出很高的要求。隨著時間和業務的發展，資料庫中的表會越來越多，表中的資料量也會越來越大，相應地，資料操作的開銷也會越來越大；另外，無論怎樣公升級硬體資源，單台伺服器的資源（cpu、磁碟、記憶體、網路io、事務數、連線數）總是有限的，最終資料庫所能承載的資料量、資料處理能力都將遭遇瓶頸。分表、分庫和讀寫分離可以有效地減小單台資料庫的壓力。
1.什麼是分割槽、分表、分庫
分割槽就是把一張表的資料分成n個區塊，在邏輯上看最終只是一張表，但底層是由n個物理區塊組成的，分割槽實現比較簡單，資料庫mysql、oracle等很容易就可支援。
分表就是把一張表按一定的規則分解成n個具有獨立儲存空間的實體表。系統讀寫時需要根據定義好的規則得到對應的字表明，然後操作它。
分庫一旦分表，乙個庫中的表會越來越多
將整個資料庫比作圖書館，一張表就是一本書。當要在一本書中查詢某項內容時，如果不分章節，查詢的效率將會下降。而同理，在資料庫中就是分割槽。2.什麼時候考慮使用分割槽？
一張表的查詢速度已經慢到影響使用的時候。
分割槽解決的問題
主要可以提公升查詢效率
分割槽的實現方式（簡單），例如：
mysql5 開始支援分割槽功能3.什麼時候考慮分表？create table sales (
id int auto_increment,
amount double not null,
order_day datetime not null,
primary key(id, order_day)
) engine=innodb
partition by range(year(order_day)) (
partition p_2010 values less than (2010),
partition p_2011 values less than (2011),
partition p_2012 values less than (2012),
partition p_catchall values less than maxvalue);
4.分表解決的問題
分表後，單錶的併發能力提高了，磁碟i/o效能也提高了，寫操作效率提高了
5.分表的實現方式（複雜）
需要業務系統配合遷移公升級，工作量較大。
6.常見分表、分庫常用策略：
1.平均進行分配hash(object)%n(適用於簡單架構)。
2.按照權重進行分配且均勻輪詢。
3.按照業務進行分配。
4.按照一致性hash演算法進行分配(適用於集群架構，在集群中節點的新增和刪除不會造成資料丟失，方便資料遷移)。
7.分庫分表中介軟體
分表又分為單庫分表（表名不同）和多庫分表（表名相同），不管使用哪種策略都還需要自己去實現路由，制定路由規則等，可以考慮使用開源的分庫分表中介軟體，無侵入應用設計，例如**的tddl等。
1、什麼是讀寫分離
讀寫分離，基本的原理是讓主資料庫處理事務性增、改、刪操作（insert、update、delete），而從資料庫處理select查詢操作。資料庫複製被用來把事務性操作導致的變更同步到集群中的從資料庫。
2、為什麼要讀寫分離呢？
因為資料庫的「寫」（寫10000條資料到oracle可能要3分鐘）操作是比較耗時的。
但是資料庫的「讀」（從oracle讀10000條資料可能只要5秒鐘）。
所以讀寫分離，解決的是，資料庫的寫入，影響了查詢的效率。
3、什麼時候要讀寫分離？
資料庫不一定要讀寫分離，如果程式使用資料庫較多時，而更新少，查詢多的情況下會考慮使用，利用資料庫 主從同步 。可以減少資料庫壓力，提高效能。當然，資料庫也有其它優化方案。memcache 或是 表折分，或是搜尋引擎。都是解決方法。
4.主從複製、讀寫分離的基本設計
在實際的生產環境中，對資料庫的讀和寫都在同乙個資料庫伺服器中，是不能滿足實際需求的。無論是在安全性、高可用性還是高併發等各個方面都是完全不能滿足實際需求的。因此，通過主從複製的方式來同步資料，再通過讀寫分離來提公升資料庫的併發負載能力。
一台主、多台從，主提供寫操作，從提供讀操作。
讀寫分離的實現：
我們只需要實現讀寫分離，主從複製資料一般由資料庫級來實現同步，當然也可以自己去實現同步，只是需要考慮的點比較多。
1.分割槽
對業務透明，分割槽只不過把存放資料的檔案分成了許多小塊，根據一定的規則把資料檔案(myd)和索引檔案（myi）進行了分割，分割槽後的表呢，還是一張表。
2.分表
當資料量大到一定程度的時候，都會導致處理效能的不足，這個時候就沒有辦法了，只能進行分表處理。也就是把資料庫當中資料根據按照分庫原則分到多個資料表當中，這樣，就可以把大表變成多個小表，不同的分表中資料不重複，從而提高處理效率。
3.分庫
分表和分割槽都是基於同乙個資料庫裡的資料分離技巧，對資料庫效能有一定提公升，但是隨著業務資料量的增加，原來所有的資料都是在乙個資料庫上的，網路io及檔案io都集中在乙個資料庫上的，因此cpu、記憶體、檔案io、網路io都可能會成為系統瓶頸。
當業務系統的資料容量接近或超過單台伺服器的容量、qps/tps接近或超過單個資料庫例項的處理極限等此時，往往是採用垂直和水平結合的資料拆分方法，把資料服務和資料儲存分布到多台資料庫伺服器上。
4.讀寫分離方案
當資料庫讀遠大於寫，查詢多的情況，就可以考慮主資料負責寫操作，從資料庫負責讀操作，一主多重，從而把資料讀寫分離，最後還可以結合redis等快取來配合分擔資料的讀操作，大大的降低後端資料庫的壓力。
有關Mysql分庫分表，讀寫分離資料庫水平拆分
web伺服器一般都是乙個伺服器連線乙個資料庫的架構，可是隨著系統的使用，該架構已經不能滿足需求了，這裡使用的是c3p0的資料庫水平擴容。spring核心配置 id propertyconfigurer class org.springframework.beans.factory.config.pr...
分庫分表與讀寫分離
隨著業務的發展，使用者數量與資料數量不斷增加，迫使進行分庫分表。所謂分表就是指將乙個表的資料存放到多個表，然後查詢時候按id的範圍到對應的表裡去查。因為資料太多，單個表已經不足以儲存。所謂分庫就是將資料存放到多個資料庫中，訪問時訪問其中乙個庫。社群已經黃了，基本不用了。不支援聯表，且依賴diamon...
資料庫分表 分庫及讀寫分離的基本概念
最近因為專案原因一直在研究分表 分庫和讀寫分離。本來打算直接使用一款開源產品，但只開源了一部分，無奈只好自己動手豐衣足食了。作者實現的簡單分布式資料來源 為什麼要分表 分庫和讀寫分離？隨著網際網路應用的廣泛普及，海量資料的儲存和訪問成為了系統設計的瓶頸問題。對於乙個大型的網際網路應用或者金融領域專案...