1 基本思想之什麼是分庫分表？從字面上簡單理解，就是把原本儲存於乙個庫的資料分塊儲存到多個庫上，把原本儲存於乙個表的資料分塊儲存到多個表上。
2 基本思想之為什麼要分庫分表？
資料庫中的資料量不一定是可控的，在未進行分庫分表的情況下，隨著時間和業務的發展，庫中的表會越來越多，表中的資料量也會越來越大，相應地，資料操作，增刪改查的開銷也會越來越大；另外，由於無法進行分布式式部署，而一台伺服器的資源（cpu、磁碟、記憶體、io等）是有限的，最終資料庫所能承載的資料量、資料處理能力都將遭遇瓶頸。
3 分庫分表的實施策略。
分庫分表有垂直切分和水平切分兩種。
3.1 何謂垂直切分，即將表按照功能模組、關係密切程度劃分出來，部署到不同的庫上。例如，我們會建立定義資料庫workdb、商品資料庫paydb、使用者資料庫userdb、日誌資料庫logdb等，分別用於儲存專案資料定義表、商品定義表、使用者資料表、日誌資料表等。
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名使用者資料，然後再對這些資料進行合併計算，才能得出結果。
資料庫分庫 分表
分庫的優點是 實現簡單，庫與庫之間界限分明，便於維護，缺點是不利於頻繁跨庫操作，單錶資料量大的問題解決不了。分表的優點是 能解決分庫的不足點，但是缺點卻恰恰是分庫的優點，分表實現起來比較複雜，特別是分表規則的劃分，程式的編寫，以及後期的 資料庫拆分移植維護。實際應用中，一般網際網路企業的路線都是先分...
資料庫分庫分表
簡單了解資料庫分庫分表，以及資料庫的分片 什麼是分庫分表 原本儲存於乙個庫的資料分塊儲存到多個庫上，把原本儲存於乙個表的資料分塊儲存在到多個表上 為什麼分庫分表 當一張表的資料達到幾千萬時，你查詢一次所花的時間會變多，如果有聯合查詢的花，我想啃根會死在那。分表的目的就在於此，減少資料庫的負擔，縮短查...
資料庫分庫分表
分庫分表 一種是按照不同的表 或者schema 來切分到不同的資料庫 主機 之上，這種切可以稱之為資料的垂直 縱向 切分 另外一種則是根據表中的資料的邏輯關係，將同乙個表中的資料按照某種條件拆分到多台資料庫 主機 上面，這種切分稱之為資料的水平 橫向 切分。垂直切分的優點 1 拆分後業務清晰，拆分規...