mysql分庫分表後序查詢操作待補充

多少條開始多表？什麼場景分庫？

單錶幾百萬條資料，對讀寫操作影響較大

資料庫分庫分表，何時分？怎樣分？詳細解讀，一篇就夠了【

1、能不切分盡量不要切分

並不是所有表都需要進行切分，主要還是看資料的增長速度。切分後會在某種程度上提公升業務的複雜度，資料庫除了承載資料的儲存和查詢外，協助業務更好的實現需求也是其重要工作之一。

不到萬不得已不用輕易使用分庫分表這個大招，避免"過度設計"和"過早優化"。分庫分表之前，不要為分而分，先盡力去做力所能及的事情，例如：公升級硬體、公升級網路、讀寫分離、索引優化等等。當資料量達到單錶的瓶頸時候，再考慮分庫分表。

2、資料量過大，正常運維影響業務訪問

這裡說的運維，指：

1）對資料庫備份，如果單錶太大，備份時需要大量的磁碟io和網路io。例如1t的資料，網路傳輸佔50mb時候，需要20000秒才能傳輸完畢，整個過程的風險都是比較高的

2）對乙個很大的表進行ddl修改時，mysql會鎖住全表，這個時間會很長，這段時間業務不能訪問此表，影響很大。如果使用pt- online-schema-change，使用過程中會建立觸發器和影子表，也需要很長的時間。在此操作過程中，都算為風險時間。將資料表拆分，總量減少，有助於降低這個風險。

3）大表會經常訪問與更新，就更有可能出現鎖等待。將資料切分，用空間換時間，變相降低訪問壓力

3、隨著業務發展，需要對某些字段垂直拆分

4、資料量快速增長

隨著業務的快速發展，單錶中的資料量會持續增長，當效能接近瓶頸時，就需要考慮水平切分，做分庫分表了。此時一定要選擇合適的切分規則，提前預估好資料容量

5、安全性和可用性

雞蛋不要放在乙個籃子裡。在業務層面上垂直切分，將不相關的業務的資料庫分隔，因為每個業務的資料量、訪問量都不同，不能因為乙個業務把數據庫搞掛而牽連到其他業務。利用水平切分，當乙個資料庫出現問題時，不會影響到100%的使用者，每個庫只承擔業務的一部分資料，這樣整體的可用性就能提高。

***********************************===mysql 分庫分表***********************************===

垂直拆分

分表：將不經常用或字段長度較大的字段拆分去擴充套件表中。

分庫：根據業務的耦合性，將關聯度低的不同表儲存在不同的資料庫中。

垂直切分的優點：

·解決業務系統層面的耦合，業務清晰

·與微服務的治理類似，也能對不同業務的資料進行分級管理、維護、監控、擴充套件等

·高併發場景下，垂直切分一定程度的提公升io、資料庫連線數、單機硬體資源的瓶頸

缺點：·部分表無法join，只能通過介面聚合方式解決，提公升了開發的複雜度

·分布式事務處理複雜

·依然存在單錶資料量過大的問題（需要水平切分）

水平拆分

水平切分的優點：

·不存在單庫資料量過大、高併發的效能瓶頸，提公升系統穩定性和負載能力

·應用端改造較小，不需要拆分業務模組

缺點：·跨分片的事務一致性難以保證

·跨庫的join關聯查詢效能較差

·資料多次擴充套件難度和維護量極大

·水平切分後同一張表會出現在多個資料庫/表中，每個庫/表的內容不同。

***********************************===mysql 分庫分表後的查詢操作***********************************===

mysql分庫分表 後序查詢操作待補充