資料庫 分庫分表以及切分策略

隨著業務和資料量的增長，單庫的io壓力越來遠大，可將單一資料庫的資料分散到多個資料庫中，來緩解資料庫的訪問壓力。

資料庫切分的兩種方式：

垂直分庫：根據業務的耦合程度，將關聯度低的表儲存在不同的資料庫中。與微服務的做法相似，每個微服務使用單獨的資料庫。

垂直分表：基於資料庫中的列進行。新建一張擴充套件表，將不經常使用或字段長度較大的字段拆分到擴充套件表中。

在字段很多的情況下，通過垂直分表，能避免跨頁問題（mysql底層通過資料頁儲存，每頁儲存16kb，一條資料占用空間過大會導致跨頁）。

另外，資料是以行為單位，將資料載入到記憶體中，垂直分表會使一行的資料變短，記憶體中能夠載入更多行資料，減少了磁碟io。

垂直切分後，可能有些單錶的資料還是非常大，這時需要對這個表上的資料進行水平切分。

水平切分便是將乙個表按照不同的規則分散到多個資料庫或多個表中。如果只做庫內水平切分，意義不大，因為單個庫內不同表的訪問，仍然會競爭同乙個物理機的cpu和記憶體。

幾種典型的資料分片規則：

1. 根據數值範圍

id區間或時間區間。比如：按照日期將不同年或月的資料放進不同的表中。將 userid 為1~9999的資料放進乙個庫，10000~19999的資料放進另乙個庫。

缺點：熱點資料被訪問的頻率很高，可能會成為效能瓶頸。

2. 根據資料取模

一般採用 hash 取模的切分方式，資料比較均勻。

比如 對 userid 取模，餘數為0的放進乙個庫，餘數為1的放進另乙個庫，以此類推。

缺點：

1. 後期集群擴容時，需要遷移舊資料（一致性hash能解決這個問題）。

2.  跨分片查詢時，效能低下。在上例中，如果查詢條件中沒有 userid，會導致無法定位資料庫，從而需要同時向多個庫同時發起查詢，再合併取並集，分庫反而成了拖累。

2.分布式事務處理複雜。

分布式事務能夠最大程度上保證資料庫操作的原子性，但在提交事務時需要協調多個資料庫節點，延長了事務的執行時間。使資料庫在訪問共享資源時，發生衝突和死鎖的概率增高。

3. 全域性主鍵重複問題

在水平切分情況下，表中資料儲存在不同資料庫中，會出現主鍵重複的問題，主鍵的自增特性也沒了用武之地。

需要設計全域性主鍵，避免跨庫主鍵重複。

資料庫分庫分表策略

一 背景 系統剛開始的時候，資料庫都是單庫單錶結構。隨著業務量的增加進行第一次資料庫公升級，根據業務垂直拆分資料庫，這樣多變成多個業務資料庫，每個資料庫裡面還是單錶結構。接下來，繼續隨著業務量的繼續增加，單錶已經很難承受資料量，就要進行分表，這個時候就是，多個業務庫，每個業務庫下對需要分表的表進行分...

資料庫分庫分表

1 基本思想之什麼是分庫分表？從字面上簡單理解，就是把原本儲存於乙個庫的資料分塊儲存到多個庫上，把原本儲存於乙個表的資料分塊儲存到多個表上。2 基本思想之為什麼要分庫分表？資料庫中的資料量不一定是可控的，在未進行分庫分表的情況下，隨著時間和業務的發展，庫中的表會越來越多，表中的資料量也會越來越大，相...

資料庫分庫 分表

分庫的優點是 實現簡單，庫與庫之間界限分明，便於維護，缺點是不利於頻繁跨庫操作，單錶資料量大的問題解決不了。分表的優點是 能解決分庫的不足點，但是缺點卻恰恰是分庫的優點，分表實現起來比較複雜，特別是分表規則的劃分，程式的編寫，以及後期的 資料庫拆分移植維護。實際應用中，一般網際網路企業的路線都是先分...