介紹
mysql分割槽後每個分割槽成了獨立的檔案，雖然從邏輯上還是一張表其實已經分成了多張獨立的表，從“information_schema.INNODB_SYS_TABLES”系統表可以看到每個分割槽都存在獨立的TABLE_ID,由於Innodb資料和索引都是儲存在".ibd"檔案當中（從INNODB_SYS_INDEXES系統表中也可以得到每個索引都是對應各自的分割槽(primary key和unique也不例外）），所以分割槽表的索引也是隨著各個分割槽單獨儲存。
在INNODB_SYS_INDEXES系統表中type代表索引的型別;0:一般的索引,1:(GEN_CLUST_INDEX)不存在主鍵索引的表,會自動生成一個6個位元組的標示值，2:unique索引,3:primary索引;所以當我們在分割槽表中建立索引時其實也是在每個分割槽中建立索引，每個分割槽維護各自的索引（其實也就是local index）；對於一般的索引(非主鍵或者唯一)沒什麼問題由於索引樹中只保留了索引key和主鍵key(如果存在主鍵則是主鍵的key否則就是系統自動生成的6個的key)不受分割槽的影響；但是如果表中存在主鍵就不一樣了，雖然在每個分割槽檔案中都存在主鍵索引但是主鍵索引需要保證全域性的唯一性就是所有分割槽中的主鍵的值都必須唯一（唯一鍵也是一樣的道理），所以在建立分割槽時如果表中存在主鍵或者唯一鍵那麼分割槽列必須包含主鍵或者唯一鍵的部分或者全部列（全部列還好理解，部分列也可以個人猜測是為了各個分割槽和主鍵建立關係），由於需要保證全域性性又要保證插入資料更新資料到具體的分割槽所以就需要將分割槽和主鍵建立關係,由於通過一般的索引進行查詢其它非索引欄位需要通過主鍵如果主鍵不能保證全域性唯一性的話那麼就需要去每個分割槽查詢了，這樣效能可想而知。
To enforce the uniqueness we only allow mapping of each unique/primary key value to one partition.If we removed this limitation it would mean that for every insert/update we need to check in every partition to verify that it is unique. Also PK-only lookups would need to look into every partition.1.主鍵分割槽
主鍵分割槽即欄位是主鍵同時也是分割槽欄位，效能最好
2. 部分主鍵+分割槽索引
使用組合主鍵裡面的部分欄位作為分割槽欄位，同時將分割槽欄位建索引
3.分割槽索引
沒有主鍵，只有分割槽欄位且分割槽欄位建索引
4.分割槽+分割槽欄位沒有索引
只建了分割槽，但是分割槽欄位沒有建索引
分割槽系列文章：
RANGE分割槽：http://www.cnblogs.com/chenmh/p/5627912.html
LIST分割槽：http://www.cnblogs.com/chenmh/p/5643174.html
COLUMN分割槽：http://www.cnblogs.com/chenmh/p/5630834.html
HASH分割槽：http://www.cnblogs.com/chenmh/p/5644496.html
KEY分割槽：http://www.cnblogs.com/chenmh/p/5647210.html
子分割槽：http://www.cnblogs.com/chenmh/p/5649447.html
指定各分割槽路徑：http://www.cnblogs.com/chenmh/p/5644713.html
分割槽介紹總結：http://www.cnblogs.com/chenmh/p/5623474.html
總結
因為每一個表都需要有主鍵這樣可以減少很多鎖的問題，由於上面講過主鍵需要解決全域性唯一性並且在插入和更新時可以不需要去掃描全部分割槽，造成主鍵和分割槽列必須存在關係；所以最好的分割槽效果是使用主鍵作為分割槽欄位其次是使用部分主鍵作為分割槽欄位且建立分割槽欄位的索引，其它分割槽方式都建議不採取。
|
備註： 作者：pursuer.chen 部落格：http://www.cnblogs.com/chenmh 本站點所有隨筆都是原創，歡迎大家轉載；但轉載時必須註明文章來源，且在文章開頭明顯處給明連結。 《歡迎交流討論》 |