【背景】

　　索引的重要是在些不表、在這里我想說的另一個問題；索引和數據一樣在innodb中都是以page的形式來組織的，那么問題就來了。

　　比如果說索引 ix_person_name 的內容只要8個頁面就能完整的保存下來，如果這個時候一條insert語句來了，由于索引的8個

　　頁面都是滿的、我們只能在新的頁面中保存這條insert(所插入數據)的索引。

?

　　1): 如果insert插入數據的索引值比當前的都要大或是都要小，那么新的索引頁面只要加入到列表的尾部或首部就行了，這兩種情況

　　相對來說還是比較“廉價”的。

?

　　2): 如果insert插入數據的索引在已有索引之間，也就是說它比最小的大、但是比最大的小。這個就要對索引頁面做“裂解”了，這個

　　這個就相對來說比較“重”了。

?

　　

【問題在哪里】

　　之所以引起“裂解”是因為在索引頁面適當的位置上沒有空間可以用來保存鍵值關系了，為了防止把頁面寫滿使得最后要做“裂解”,數據庫

　　引入了一個“填充因子”的概念，比如說填充因子設置為80%就是說當頁面中的空間80%都已經寫入數據之后就可以為索引分配新的頁面

　　了，不要等到頁面空間用完。 這個就是期望通過多個相對“廉價”的操作來避免“重”的操作。

?

　　

【副作用也不小】

　　由于“填充因子”是80%所以之前8個頁面就可以保存下來的內容現在用了10個頁面，由于操作是以頁面為單位的所以最“糟糕”的情況下

　　數據庫的多了20%的開銷(當然事實上并沒有這么多、這只是從頁面數據數量這個維度來說的)。

?

　　以上所說的還不是全部、通常真實的填充率不太可能有80%；比如說在經歷過一段時間的oltp之后，有一些數據被刪除了，所以這些

　　數據所對應的索引內容也會被回收、這些內容之前占的空間可能就是先放著等著后面的重用。

?

　　假設數據量沒有變多少，可以實際上的填充率由之前的80%下降到了10%，極端數據庫的工作量又增加了。

?

　　總的來說索引在頁面中排列的越是“緊密”對于讀來說它可以明顯的減小開銷，但是這個會增大寫的開銷。之前DBA只能“暗中觀察”，

　　不能“有所作為”，但是MySQL-8.0.x版本下變天了；DBA可以在一定程序上左右“歷史的進程”！

?

【手段】

　　在mysql-8.0.x中DBA可以指定索引頁面合并的閥值，比如說把閥值設置為50%也就是說當相鄰的兩個索引頁面，當他們的填充率

　　都小于或等于50%的情況下就可能把這兩個頁面合并成一個頁面。也就是說索引頁面合并有利于“讀”操作

?

【例子】

　　假設我們有一個person表并把name列的索引的合并閥值設置為45%，birthday列索引的閥值設置為48%　　

use tempdb;create table person(id int not null auto_increment primary key,name varchar(16),birthday datetime default now());create index ix_person_name on tempdb.person(name) comment 'MERGE_THRESHOLD=45';create index ix_person_birthday on tempdb.person(birthday) comment 'MERGE_THRESHOLD=48';

　　1):?MERGE_THRESHOLD 是以comment的形式體現在SQL中的、MySQL并沒有為它單開一個子句

　　2):?MERGE_THRESHOLD 只能是大寫的小寫的話會被“無視”

?

【可以從information_schema中查詢索引頁的合并閥值】

select * from INNODB_INDEXES where name in ('ix_person_name','ix_person_birthday') ; +----------+--------------------+----------+------+----------+---------+-------+-----------------+ | INDEX_ID | NAME | TABLE_ID | TYPE | N_FIELDS | PAGE_NO | SPACE | MERGE_THRESHOLD | +----------+--------------------+----------+------+----------+---------+-------+-----------------+ | 147 | ix_person_name | 1059 | 0 | 2 | 5 | 2 | 45 | | 148 | ix_person_birthday | 1059 | 0 | 2 | 6 | 2 | 48 | +----------+--------------------+----------+------+----------+---------+-------+-----------------+ 2 rows in set (0.01 sec)

?

?

----

?

轉載于:https://www.cnblogs.com/JiangLe/p/10108945.html

總結

以上是生活随笔為你收集整理的MySQL-8.0.x 新特性之索引页合并的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。