之前已經介紹過了schema的作用了，這篇會把rule和server一起介紹~
首先是rule，而這個文件裡面會詳細的製定多種分片的規則，這次只抽出一些使用率比較高的方法，先上檔案的內容
## 截圖的上半部分描述的是rule的定義，在下半部分，是rule對應的實際切分規則，這裡總工介紹下面四種切分方式~murmur已坑~
- -------------------------------------------------- ----------------------------------------Hash-int------- -------------------------------------------------- --------------------------------
先看hash-int，在這條切分規則的下面，有一個mapfile，這代表著，這個切分規則是根據partition-hash-int的內容來決定的，那麼看一下這個文本檔
#很簡單的內容，這代表著切分使用的基準列裡面，值為10000的時候，放在第一個DN裡面（dn1），值為10010的時候，放在第二個DN裡面（dn2）
可以看一下實際效果
Debug日誌，這兩個語句被分配到了dn1和dn2上面，資料庫裡面也插入了相對應的資料
（挖土機滾粗~），如果插入的資料中，基準列的取值不是這個文件裡面寫明的值，會是什麼效果？ 
對上了當的錯誤回報了~## ，大體上可以理解為
枚舉分區
，會比較適合於取值固定的場合，比如說性別（0,1），省份（固定值，短時間不會收復日本省吧～），通路商
or 各種平台的ID
而且，用逗號分隔可以把多個值放在一個分區裡面，所以可以根據實際的資料量/流量/訪問量來綜合製定切分策略；
不是全能戰士╮(╯_╰)╭
#---------------------- -------------------------------------------------- -------------------range-long---------------------------- -------------------------------------------------- ---
第二種切分方式，range-long，仔細一看的話，和hash-int是比較像的，也是由特定的文件來決定切分策略，所以還是去看一下文件的內容
從文件內容中看出，這是一種範圍切分的方式，制定基準列的值範圍，然後將此範圍的所有資料都放到一個DN上面，這上面種方式和hash-int基本上一致，就不截圖了（懶癌晚期，時間不夠了！）
這種切分策略，個人感覺在業務資料庫裡面的使用場景會少一些，因為這種切分方式需要預定好整體的數量，這就決定了那種無限增長的數據不能用這個，畢竟要改動這個切分策略會很麻煩
真要用起來，感覺也就對自增主鍵用，然後依照一定的數量來均勻切分，例如那種一天固定X條資料的業務（溫度採集？資料收集？之類的情況），然後提前建好多個DN（庫）。
當然，且有一個潛在的問題，如果在短時間發生海量的順序插入操作，而每一個DN（分庫）設定的數量比較高(比如說一個DN設定的放1000W條資料),那麼在這個時候,會出現某一個DN（分庫）IO壓力非常高，而其他幾個DN（分庫）完全沒有IO操作，就會出現類似DB中常見的熱塊/熱盤的現象，而MySQL常用自增主鍵，所以使得MySQL的表出現大量「順序」插入的機會會多很多 。
-------------------------------------------- ------------------------------------------------mod- long------------------------------------------------- ----------------------------------
mod-long，從mod來看這應該是取餘數的方法，來看看特定配置的資訊
count=4，這是代表著總共將資料切分成四份，一般是和特定的DN數量對應，從而將對應達到把資料均勻的分佈在四個DN上（當然，count 看實際的效果
如何處理的
以這種取餘數的方式時，這四個資料分別插入了四個DN（資料庫），並且可以看到，當順序插入時，資料是被分割在多個DN（庫）上面
相比較於上面的range的方法，這種切分策略會更好的分散資料庫寫的壓力，但是問題也很明顯，一旦出現了範圍查詢，就需要MyCAT去合併結果，當資料量偏高的時候，這種跨庫查詢+合併結果消耗的時間有可能會增加很多，尤其是還出現了order
by的時候。
所以這種切分策略會比較適合單點查詢的情景，比如說.....我也不知道......真的不知道,也許在銀行,查詢個人帳戶資訊的時候,一些和用戶資訊的表可以做好冗餘,然後利用這種方式來提供更為高效的查詢(畢竟銀行的用戶數量多,恩恩~)
#----------------------------------------- ---------------------------------------partition-by-long------ -------------------------------------------------- --------------------------
partition-by-long,處於range-long和mod -長之間的一個略微折中的分割策略,具體切分形勢依如下說明:
以1024為一個單位,每個DN存放partitionLength數量的資料,且,partitionCount x partitionLengthCount x partitionLength =1024
看起來有點難以理解,形象點描述的話,以partitionCount(4) x partitionLength(256)為例,sid%1024=0-255的放在11256-DN51的放在DN2,以此類推
試著以128為偏移值插入了八條數據，直接看MyCAT的日誌
#卷個DN裡面~
值得一提的是，這種切分策略也支持非均勻分佈~實在是測不動了，盜圖兩張~
兩張圖基本上也說明白了這個非均勻分佈的分割策略，重點還是在2x256+1x512=1024上面
此分割策略在
range-long和mod-long之間取了一個折中點，同時，也算是比較靈活，可以根據不同的情況進行非均勻劃分，實際上能應用的場景會稍微多一點吧，或者說，不少場景都能用一用，相對減少了跨DN的情形，又把資料比較均勻的切分開來了，單點查詢也不會太慢。
----------------------------- -------------------------------------------------- ----寫在最後------------------------------------------------- ------------------------------------------其實MyCAT支援的切分方式還有不少，比如說按照時間的切分策略，可以按月，按天切分等，在這裡也沒辦法把所有的策略都放上來，見諒了o(￣ヘ￣o＃)實際上從個人的觀點來看，時間的切分依照資料庫本身的分區策略來分也沒什麼問題，半年度，季度的數據也還是會需要查詢的....PS： _(:з”∠)_真不是懶... 可以說，MyCAT的分庫分錶的重點，基本上全部都在這個rule裡面體現了，表要不要分，表的數據怎麼切分，都是需要根據實際業務來決定，充分根據業務的特徵去決定最合適的劃分策略~
以上是MySQL分散式叢集之MyCAT（三）rule的詳細分析（圖文）的詳細內容。更多資訊請關注PHP中文網其他相關文章！
