從業務場景看分庫分表

互聯網行業中，業務場景通常寫少讀多的情況居多，在MySQL的使用前期，讀性能大多可以通過SQL優化來解決，但隨著業務的持續發展，單純依靠SQL的查詢優化會越來越難以達到業務服務要求。

因此，量級較大的業務場景，MySQL的讀壓力往往會首先成為系統瓶頸所在。

此時，在數據庫層面，DBA通常會建議通過橫向擴展備庫節點的方式，采用讀寫分離技術來提升業務系統的讀性能、讀并發能力。

以上是典型的互聯網讀寫分離需求。

除了這種多見的讀瓶頸問題，在大型網站和海量數據的業務場景，數據庫常見的性能瓶頸下面的兩地問題會更加突出：

一是大量的并發讀寫操作，導致單庫出現負載壓力過大；

二是單表存儲數據量過大，導致查詢效率低下。

該種情況，由于業務的讀寫請求較高，MySQL在主從之間的數據同步容易引發主從延遲問題。改進的做法是，我們可能會架構設計上，需要敦促業務在寫入主庫之前最好將同一份數據落到緩存，以避免高并發場景下從從庫中獲取不到指定數據的情況發生。

如果寫壓力進一步擴大，并且數據量急劇快速增長，DB寫節點即主庫就會成為整個系統的瓶頸。在MySQL的日常運營中，如果DB中表和表之間的數據很多是沒有關系的，或者根本不需要表關聯Join操作，我們可以考慮按照業務把不同的數據放到不同的服務器中，即垂直分庫或叫垂直切分。

不過需要注意的是，垂直分庫無法解決單表數據量過大的問題，由于單一業務的數據信息仍然落盤在單表中，如果單表數據量太大，就會極大地影響SQL執行的性能。

由此，在MySQL應用領域，水平分表也是互聯網場景應對高并發、單表數據量過大的解決方案之一。

分表在本質上可以概括為業務表在邏輯上公用一個路由結構，物理上分散存儲。這就是常說的Sharding分片或者分區。

比如以用戶ID字段user_id按照一定策略(hash、range等)，將表中數據拆分到多個子表中(分片或分區)，以確保子表中數據量在讀寫性能可接受的范圍內。每個子表的結構都一樣，每個表的數據都不一樣，沒有交集，所有表的并集是全量數據。

水平分表主要用于業務架構無法繼續垂直細分、數據庫中單張表數據量太大、查詢性能下降的場景。

應該使用哪一種方式來實施數據庫分庫分表，需要從數據庫的瓶頸所在和項目的業務角度進行綜合考慮。如果數據庫是因為表太多而造成海量數據，并且項目的各項業務邏輯劃分清晰、耦合度較低，建議優先使用垂直切分。

如果數據庫中的表并不多，但單表的數據量很大且數據熱度很高，這種情況之下就應該選擇水平切分。

在現實項目中，往往是這兩種情況兼而有之，綜合使用了垂直與水平切分，我們首先對數據庫進行垂直切分，然后針對一部分表進行水平切分。

但是，采用分庫分表也會引入新的問題。

分庫分表存在的問題及注意點

l跨庫Join問題

分庫分表后，表之間的關聯操作將受到限制，無法join位于不同分庫的表，也無法join分表粒度不同的表，結果導致原本一次查詢能夠完成的業務可能需要多次查詢才能完成。

因此，分庫分表的設計，需要結合業務數據的關聯場景，適當考慮數據的冗余和拆分策略。比如：根據之前表之間的關系，將相關表以相同的拆分策略，確保關聯數據存放到一個分片上。或者使用表級冗余將基礎數據在所有庫都寫一份。使用字段冗余：把需要join的字段冗余在各個表中，這樣有些字段就不用join去查詢了。再者就是在應用邏輯層進行數據組裝：將原來的請求分兩次查詢，在第一次查詢的結果集中找出關聯數據id，然后根據id發起第二次請求得到關聯數據，最后將獲得到的數據進行字段拼裝。

l 排序合并問題

由于數據的分庫、分片導致的分散存儲，原來的業務請求會引發結果集合并、排序問題。尤其是當排序字段不是分片字段的似乎，問題會變得比更加復雜。

需要先在不同的分片節點中將數據進行排序并返回，然后將不同分片返回的結果集進行匯總和再次排序，最終返回給用戶。

因此，分庫分表，還需要考慮業務具體的排序場景，盡量保障排序字段和分布鍵一致，確保請求通過分片規則就比較容易定位到指定的分片。

l 遷移和擴容問題

遷移和擴容，屬于DB日常運營中常規場景。分庫分表后，如果數據采用的是數值范圍range分片，那么我們只需要添加節點就可以進行擴容;但如果采用的是數值hash取模分片，由于擴容涉及數據重分布過程，擴容相對比較麻煩。

所以，分庫分表，需要根據業務當前、預期的數據量、QPS來進行容量規劃，推算

出大概需要多少分片，盡量減少后續擴容及遷移的發生。

l分布式事務問題

由于分庫分表之后，業務需要跨庫跨分片進行SQL請求，類似分布式事務的問題就會出現。為了確保事務的原子性，事務的提交需要協調多個節點，加大事務的執行時間及復雜性。

因此，對于性能要求很高，但對一致性要求不高的系統，在分庫分表設計的實時候可能需要采用事務補償的方式，將實時一致性轉化為最終一致性，結合業務系統比如對數據進行對賬檢查、基于日志進行對比等進行事后補償。

總 結

分庫分表作為一種橫向擴展的解決方案，問題還是比較明顯的：

從運維側來看：會極大的加大系統的復雜度、運維成本相對較高；

從業務側來看：會極大增加開發編碼工作量，并使業務邏輯復雜化。

所以，如果無需分片，則盡量避免分庫分表；如果確實到了需要分庫分表的情況，相對分庫分表的通用方案，如果采用分布式中間件或原生分布式數據庫，業務側無需花大量的工作來處理如何分片和分片后的問題，有更多的時間原本該是專注于業務的應用。

總結

以上是生活随笔為你收集整理的mysql 横向分表合并_MySQL横向扩展-分库分表解决方案总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。