MySQL 分區建索引


介紹

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

本站點所有隨筆都是原創,歡迎大家轉載;但轉載時必須注明文章來源,且在文章開頭明顯處給明鏈接。

《歡迎交流討論》


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM