分表分庫雖然能解決大表對數(shù)據(jù)庫系統(tǒng)的壓力，但它并不是萬能的，也有一些不利之處，因此首要問題是，分不分庫，分哪些庫，什么規(guī)則分，分多少分片。 
原則一：能不分就不分，1000萬以內(nèi)的表，不建議分片，通過合適的索引，讀寫分離等方式，可以很好的解決性能問題。 
原則二：分片數(shù)量盡量少，分片盡量均勻分布在多個DataHost上，因為一個查詢SQL跨分片越多，則總體性能越差，雖然要好于所有數(shù)據(jù)在一個分片的結(jié)果，只在必要的時候進行擴容，增加分片數(shù)量。 
原則三：分片規(guī)則需要慎重選擇，分片規(guī)則的選擇，需要考慮數(shù)據(jù)的增長模式，數(shù)據(jù)的訪問模式，分片關(guān)聯(lián)性問題，以及分片擴容問題，最近的分片策略為范圍分片，枚舉分片，一致性Hash分片，這幾種分片都有利于擴容 
原則四：盡量不要在一個事務(wù)中的SQL跨越多個分片，分布式事務(wù)一直是個不好處理的問題 
原則五：查詢條件盡量優(yōu)化，盡量避免Select * 的方式，大量數(shù)據(jù)結(jié)果集下，會消耗大量帶寬和CPU資源，查詢盡量避免返回大量結(jié)果集，并且盡量為頻繁使用的查詢語句建立索引。 


如果某個表的數(shù)據(jù)有明顯的時間特征，比如訂單、交易記錄等，則他們通常比較合適用時間范圍分片，因為具有時效性的數(shù)據(jù)，我們往往關(guān)注其近期的數(shù)據(jù)，查詢條件中往往帶有時間字段進行過濾，比較好的方案是，當(dāng)前活躍的數(shù)據(jù)，采用跨度比較短的時間段進行分片，而歷史性的數(shù)據(jù)，則采用比較長的跨度存儲。 
總體上來說，分片的選擇是取決于最頻繁的查詢SQL的條件，因為不帶任何Where語句的查詢SQL，會便利所有的分片，性能相對最差，因此這種SQL越多，對系統(tǒng)的影響越大，所以我們要盡量避免這種SQL的產(chǎn)生。

當(dāng)前文章：Mycat分表分庫原則
標(biāo)題鏈接：http://jinyejixie.com/article6/gpeiog.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供App開發(fā)、動態(tài)網(wǎng)站、靜態(tài)網(wǎng)站、品牌網(wǎng)站建設(shè)、定制開發(fā)、微信小程序

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)