-
一、背景
隨着業務的不斷擴展和業務量的快速增加，數據量就會越來越大，每次對錶的操作都會佔用更多的系統資源，若單表數據量過大，索引又多，這時候插入數據處
理速度就會變的很慢，這時候單機性能瓶頸就凸顯出來了，那麼如何解決呢？
映射到日常生活中，在一定條件下，把一件事分配給幾個人一同處理的速度遠大於一個人去處理的速度跟效率，這樣即可以減輕每個人的壓力，也可以提升整件事的
處理速度跟效率，但是要付出的人工成本就變高了，但是如果業務發展良好的話，從長遠來看，收益將是投入成本的好多倍，其實是賺了。
所以可以考慮 兩種方案:
1.部署上：採用 主從複製、讀寫分離。
2. 數據切分：將大數據表切分 散佈到多個數據庫主機上，達到均衡負載，突破單機性能瓶頸。
-
二、方案分析
第一種：主從複製 讀寫分離。這種是從部署方面來說的，但是隨着業務量的不斷增加和擴展，還是解決不了表數據量過大單機性能瓶頸的問題 插入、查詢、位數索引文件過慢的問題。倘若遇見流量高峯期，或者併發期的時候，數據庫有可能掛掉。所以這種方案也不能從根本上解決問題。但是這種部署方案幾乎是大多數網站通用的部署的方式。可以考慮跟 方案2 和 方案3 相結合，做到優勢互補。
第二種：
1. 垂直切分：可以根據一個業務涉及到的表之間的耦合度高低來切分，把一個業務中耦合度低的表，散佈到多個數據庫中，它們之間的耦合度低，相對於業務來說邏輯關聯性也弱，沒有那麼多的join操作，較容易拆分，應用層的改動也較小，付出的成本也較低。例如把會員表和訂單表放在不同的數據庫中，但是這種方式缺點：
(1) 由於業務部分複雜度較高需要join操作，這就不好辦了，只能通過應用程序或接口方式解決,如果部分業務需要事物方式處理，也是個頭疼的問題，也不利於事務處理。
(2)當數據量達到一定規模還是會出現單庫性能瓶頸
2.水平切分：把一個大表中的部分數據做切分 散佈到多個數據庫中，比如機構預約表，每天都會產生好幾萬條記錄，可以根據機構的id取模運算，分散到不同數據表或者數據庫中，水平切分可避免單表數據量過大影響查詢和插入性能，減少佔用系統資源，大流量或者併發場景下 數據庫掛掉的可能行降低。
缺點：
(1)跨庫join難度增加
(2)分佈式事務處理複雜
總結：可以看出這兩種切分方案：基本都存在 跨庫join 問題、分佈式事務處理繁雜問題。所以在設計表的時候一定要根據業務模型 找出最優切分方案。一般不是很大的系統中，可能只有部分業務數據量比較大，所以只有部分表需要做拆分，這個還比較好處理，但是大型系統就不能這麼幹了，不然付出的改造維護成本和時間成本會非常大。 現在有很多開源的數據庫中間件，所以建議用數據庫中間件來做處理，應用層只做應用層該做的事，不用考慮那麼多，一些繁雜的數據處理交給中間件來做處理，這樣開發效率也會大大提高。
