1. 程式人生 > >MySQL 分割槽建索引

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.