mysql知識擴充套件之分庫分表

mysql網際網路oracle企業應用資料結構 .

資料庫的複製能解決訪問問題，並不能解決大規模的併發寫入問題，要解決這個問題就要考慮mysql資料切分了 www.2cto.com

資料切分，顧名思義，就是資料分散，將一台主機上的資料分攤到多台，減輕單台主機的負載壓力，有兩種切分方式，一種是分庫，即按照業務模組分多個庫，每個庫中的表不一樣，還有一種就是分表，按照一定的業務規則或者邏輯將資料拆分到不同的主機上，每個主機上的表是一樣的，這個有點類似於oracle的表分割槽。

分庫又叫垂直分割槽，這種方式實現起來比較簡單，重要的是對業務要細化，分庫時候要想清楚各個模組業務之間的互動情況，避免將來寫程式時出現過多的跨庫操作。

分表又叫水平分割槽，這種方式實現起來就比垂直分割槽複雜些，但是它能解決垂直分割槽所不能解決的問題，即單張表的訪問及寫入很頻繁，這時候就可以根據一定的業務規則（ps:如網際網路bbs論壇的會員等級概念：根據會員等級來分表）來分表，這樣就能減輕單錶壓力，並且還能解決各個模組的之間的頻繁互動問題。

www.2cto.com

分庫的優點是：實現簡單，庫與庫之間界限分明，便於維護，缺點是不利於頻繁跨庫操作，單錶資料量大的問題解決不了。

分表的優點是：能解決分庫的不足點，但是缺點卻恰恰是分庫的優點，分表實現起來比較複雜，特別是分表規則的劃分，程式的編寫，以及後期的資料庫拆分移植維護。

實際應用中，一般網際網路企業的路線都是先分庫再分表，兩者結合使用，取長補短，這樣發揮了mysql擴充套件的最大優勢，但是缺點是架構很大，很複雜，應用程式的編寫也比較複雜。

以上是mysql的資料切分的一些概念，資料切完了，現在要做的是怎麼樣在整合起來以便於外界訪問，因為程式訪問的入口永遠只有乙個，現在比較常用的解決方案是通過中間**層來統一管控所有資料來源。

常用的**層方案：

1.mysql proxy

類似於連線池，所有連線通過它進行**。

2.amoeba

是乙個開發**層的框架，有對應版本amoeba for mysql,對於資料切分規則，連線數控制，以及讀寫分離路由支援較好。

3.hivedb

僅支援水平切分，底層由hibernate shards實現。

4.其他 www.2cto.com

hscale,spock proxy(ror),pyshards(python)

最後值得注意的是mysql分庫分表的缺點：

缺少好的分布式事務解決方案，目前僅有innodb提供解決方案，效能值得商榷。

缺少類似於dblink的跨節點sql解決方案，federated提供支援了，但是還是簡單的支援，對於表結構的變化就不能為力。

這些缺點只能通過應用程式層來解決，不過話說回來，如果所有缺點都解決了，oracle也不會賣那麼貴了。