什麼是分割槽？

資料庫分割槽一般指的是資料庫的表分割槽，下面我們以MYSQL為例來講解資料庫分割槽，其他資料庫道理基本相同。分割槽表對使用者來說是一個邏輯整體，但底層mysql將其分離為多個物理子表，分割槽對於sql來說是完全封裝的，也就是對我們應用來說是透明的，不可見的，但從底層的檔案系統來看，一個表被分割為多個子表文件，使用方法也很簡單，在建立表時使用 partition by 子句定義分割槽表示式來存放資料。

mysql執行查詢時候，最佳化器先根據分割槽表示式的定義來過濾無用的分割槽，執行sql時只需要查詢包含需要的資料分割槽就可以了。

分割槽的原理？

分割槽表管理一組分割槽表和管理普通表一樣，各個子表的索引也是上加了一個人完全相同的索引，從儲存引擎來看，子表和一個獨立的普通表沒有任何區別，以下我們來看看當執行以下命令的時候mysql如何操作分割槽表的：

select ：查詢時，分割槽層開啟並鎖住所有子表，最佳化器先根據分割槽表示式過濾不需要的分割槽，然後呼叫儲存引擎訪問各個目標分割槽。insert：寫入時，分割槽層開啟並鎖住所有子表，根據分割槽表示式確認存放資料的分割槽是哪一個，再去指定分割槽插入記錄。delete：刪除也是一樣，還是先鎖住所有分割槽，根據分割槽表示式確認資料在哪一個分割槽，再去那個分割槽刪除記錄。update：更新時相對複雜一點，分割槽層開啟並鎖住所有子表，先根據分割槽表示式確認資料在哪一個分割槽，然後先取出資料並更新，再判斷更新後的資料應該存放哪個分割槽，最後對目標分割槽寫入資料，最後一步要對原始資料的分割槽表進行刪除操作。分割槽型別有哪些？範圍分割槽：使用partition by range（列的表示式）來表示，使用最多的分割槽表型別，每個分割槽儲存某個範圍內的資料，比如：列表分割槽：使用 partition by list（列的表示式） 按離散值集合分割槽，這種分割槽型別類似於範圍分割槽，例如：雜湊分割槽：使用 partition by hash（列的表示式），按表示式的hashcode取模後分布到指定的區域，同理：分割槽查詢最佳化？

分割槽資料顯而易見的好處是資料分塊管理，大表拆小表，這樣在操作資料的時候可以預先過濾掉不必要的資料，儘量控制在一個較小的資料區來查詢資料。一個很重要的意見是：儘量在where條件中帶入分割槽列查詢，如果沒有mysql就會掃描所有分割槽，我們可以使用expain patitions 來檢視sql語句是否使用了分割槽過濾，如：

explain partitions select * from tuser

結果顯示掃描的所有分割槽，我們再加上where條件：

explain partitions SELECT * from tuser where cid=2000

結果顯示只掃描了一個分割槽。

為什麼要使用資料分割槽？表資料非常大後使用索引的代價過大、表資料呈現明顯的熱點資料。分割槽表的資料更容易維護，可以單獨的針對子表進行最佳化和修復工作，也可以操作整個分割槽資料。分割槽子表的資料可以部署到不同的物理裝置上，可以高效的利用多個硬體裝置。由於一個大表資料分散到多個子表中，這樣可以避免單個索引的互斥和鎖的競爭。常見的問題有哪些？一個表最多隻能有1024個分割槽。分割槽過多可能會導致在進行分割槽重組（重組會涉及到臨時資料表的複製和刪除）、表資料更新、分割槽查詢的時候開銷過大。執行命令前mysql會鎖住所有分割槽表，這個操作是在過濾分割槽和執行sql語句之前執行的，所以這個開銷無法避免，最好的做法是控制分割槽表數量在100個以內。分割槽表示式的返回值必須是整數。分割槽表無法使用外來鍵。null值會使分割槽過濾無效。mysql5.5以後對分割槽表做了大範圍的最佳化和bug修復，所以使用這個特性之前確保你mysql高於5.5版本。分割槽列和索引類不匹配，如果我們在某些列上建立了索引，但這些列又不參與分割槽，即 partition by 型別（列的表示式）子句不包含這些索引列，那麼mysql在掃描這些索引的時候會遍歷所有分割槽表的索引，除非where子句使用了分割槽列來查詢，為了避免這個問題儘量使用索引列來分割槽，比如：

資料分割槽是一種物理資料庫的設計技術，它的目的是為了在特定的SQL操作中減少資料讀寫的總量以縮減響應時間。要搞清楚資料庫分割槽，先要清楚一下問題

為什麼要分割槽

在實際工作中隨著業務的增長，我們的資料庫資料越來越大，隨之而來的是單個表中資料太多。以至於查詢速度變慢，而且由於表的鎖機制導致應用操作也受到嚴重影響，出現了資料庫效能瓶頸。

也就是說當表中的資料量不斷增大，查詢資料的速度就會變慢，應用程式的效能就會下降，這時就應該考慮對錶進行分割槽。表進行分割槽後，邏輯上表仍然是一張完整的表，只是將表中的資料在物理上存放到多個表空間(物理檔案上)，這樣查詢資料時，不至於每次都掃描整張表。為了提高資料庫效能，保證資料的準確無誤以及安全性。所以要進行分割槽。

資料庫分割槽的概念和原理

分割槽並不是生成新的資料表，而是將表的資料均衡分攤到不同的硬碟，系統或是不同伺服器儲存介子中，實際上還是一張表。

要實現這一功能，首先要了解資料庫對水平分割槽表進行分割槽儲存的原理。

為了方便理解資料分割槽，在這裡先介紹一下分表的概念。分表是將一個大表按照一定的規則分解成多張具有獨立儲存空間的實體表，每個表都對應三個檔案，MYD資料檔案，.MYI索引檔案，.frm表結構檔案。這些表可以分佈在同一塊磁碟上，也可以在不同的機器上。app讀寫的時候根據事先定義好的規則得到對應的表名，然後去操作它。

資料庫分割槽和分表相似，都是按照規則分解表。不同在於分表將大表分解若干個獨立的實體表，而分割槽是將資料分段劃分在多個位置存放，分割槽後，表還是一張表，但資料雜湊到多個位置了。應用程式讀寫的時候操作還是表名，DB自動去組織分割槽的資料。

所謂水平分割槽分表，就是把邏輯上的一個表，在物理上按照你指定的規則分放到不同的檔案裡，把一個大的資料檔案拆分為多個小檔案，還可以把這些小檔案放在不同的磁碟下。這樣把一個大的檔案拆分成多個小檔案，便於我們對資料的管理。

資料庫分割槽的優勢

分割槽可以做到將表的資料均衡到不同的地方，提高資料檢索的效率，降低資料庫的頻繁IO壓力值，目的是為了在特定的SQL操作中減少資料讀寫的總量以縮減響應時間。

1、相對於單個檔案系統或是硬碟，分割槽可以儲存更多的資料；

3、精準定位分割槽查詢資料，不需要全表掃描查詢，大大提高資料檢索效率；

4、可跨多個分割槽磁碟查詢，來提高查詢的吞吐量；

5、在涉及聚合函式查詢時，可以很容易進行資料的合併；

關於資料庫分割槽，分表，分庫，我通俗易懂的來舉幾個栗子，看過還不懂，你打我。。。

村裡一家四口人(老爹叫A)有兩兒子(分別是A1，A2)，長大了要自己種地了，就嚷嚷著要分家，把村東的一塊地給大兒子A1，村西的給二兒子A2，但是這時候戶口本上記錄的還是一家四口(對外顯示還是一家人)，國土局統計村西土地面積的時候直接讓A去彙報，然後A去讓A2測量並彙報，不涉及到A1！

這就是分割槽:對外只展示一張表，但是表內部分割槽到不同的磁碟上，只需要其中一部分資料的時候可直接對映相應的區進行查詢，避免了全表掃描，提升了查詢，插入資料的效能，一般是資料庫層面實現的，如下圖所示:

分割槽可分為水平分割槽和垂直分割槽，通常水平分割槽用的比較多，演算法有按照某個欄位的大小等，某個欄位的hash分等等！

啥是分表呢？還是上面那一家子，分家了之後，戶口也變了，變成了三家，國土局讓上報資料的時候，需要分別通知三家進行，比如只需要村西的統計，那麼還是隻用找二兒子A2就行了(三家已經是單獨的資料庫表了)

分表:對外展示多張小表，業務程式碼訪問之前，需要先透過計算分表策略演算法，來選擇具體訪問哪一張表，和分割槽一樣，避免了全表的訪問，分表如下圖示:

分庫:跟分表有異曲同工之妙，但是分庫的級別為資料庫級別(按上面的例子，就得提升到村子級別了)，簡單來說就算是你一個庫是關係型資料庫，一個庫是nosql資料庫也是可以稱為分庫的，這對於庫的引擎，連線方式都可以有不同的實現！

分庫通常在不同的資料庫服務節點上，避免單庫宕機對全部資料服務帶來的影響，同時也提供了更大的資料庫併發能力！關於分庫，分表，分割槽是不是很簡單？

現在分庫分表使用的更加的廣泛，業界也提供了大量成熟的資料庫中介軟體來提供分庫分表，比如mycat，sharding-jdbc等等，只需要根據業務選擇合適的分庫分表策略，結合相應元件就能輕鬆搭建起一個分庫分表資料服務，不過隨之而來的全域性唯一資料，統計，連線查詢等才是更加需要關注的，更多的技術分享，敬請關注。。。