共計 1242 個字符，預(yù)計需要花費 4 分鐘才能閱讀完成。

自動寫代碼機器人，免費開通

MySQL 主鍵自增的原因？這個問題可能是我們?nèi)粘W習或工作經(jīng)常見到的。希望通過這個問題能讓你收獲頗深。下面是丸趣 TV 小編給大家?guī)淼膮⒖純?nèi)容，讓我們一起來看看吧！

InnoDB 引擎表的特點

1、InnoDB 引擎表是基于 B + 樹的索引組織表(IOT)

關(guān)于 B + 樹

B+ 樹的特點:

所有關(guān)鍵字都出現(xiàn)在葉子結(jié)點的鏈表中(稠密索引)，且鏈表中的關(guān)鍵字恰好是有序的;

不可能在非葉子結(jié)點命中;

非葉子結(jié)點相當于是葉子結(jié)點的索引 (稀疏索引)，葉子結(jié)點相當于是存儲(關(guān)鍵字) 數(shù)據(jù)的數(shù)據(jù)層;

2、如果我們定義了主鍵(PRIMARY KEY)，那么 InnoDB 會選擇主鍵作為聚集索引、如果沒有顯式定義主鍵，則 InnoDB 會選擇第一個不包含有 NULL 值的唯一索引作為主鍵索引、如果也沒有這樣的唯一索引，則 InnoDB 會選擇內(nèi)置 6 字節(jié)長的 ROWID 作為隱含的聚集索引(ROWID 隨著行記錄的寫入而主鍵遞增，這個 ROWID 不像 ORACLE 的 ROWID 那樣可引用，是隱含的)。

3、數(shù)據(jù)記錄本身被存于主索引（一顆 B +Tree）的葉子節(jié)點上。這就要求同一個葉子節(jié)點內(nèi)（大小為一個內(nèi)存頁或磁盤頁）的各條數(shù)據(jù)記錄按主鍵順序存放，因此每當有一條新的記錄插入時，MySQL 會根據(jù)其主鍵將其插入適當?shù)墓?jié)點和位置，如果頁面達到裝載因子（InnoDB 默認為 15/16），則開辟一個新的頁（節(jié)點）

4、如果表使用自增主鍵，那么每次插入新的記錄，記錄就會順序添加到當前索引節(jié)點的后續(xù)位置，當一頁寫滿，就會自動開辟一個新的頁

5、如果使用非自增主鍵（如果身份證號或?qū)W號等），由于每次插入主鍵的值近似于隨機，因此每次新紀錄都要被插到現(xiàn)有索引頁得中間某個位置，此時 MySQL 不得不為了將新記錄插到合適位置而移動數(shù)據(jù)，甚至目標頁面可能已經(jīng)被回寫到磁盤上而從緩存中清掉，此時又要從磁盤上讀回來，這增加了很多開銷，同時頻繁的移動、分頁操作造成了大量的碎片，得到了不夠緊湊的索引結(jié)構(gòu)，后續(xù)不得不通過 OPTIMIZE TABLE 來重建表并優(yōu)化填充頁面。

綜上總結(jié)，如果 InnoDB 表的數(shù)據(jù)寫入順序能和 B + 樹索引的葉子節(jié)點順序一致的話，這時候存取效率是最高的，也就是下面這幾種情況的存取效率最高：

使用自增列 (INT/BIGINT 類型) 做主鍵，這時候?qū)懭腠樞蚴亲栽龅模?B + 數(shù)葉子節(jié)點分裂順序一致；

該表不指定自增列做主鍵，同時也沒有可以被選為主鍵的唯一索引(上面的條件)，這時候 InnoDB 會選擇內(nèi)置的 ROWID 作為主鍵，寫入順序和 ROWID 增長順序一致；

除此以外，如果一個 InnoDB 表又沒有顯示主鍵，又有可以被選擇為主鍵的唯一索引，但該唯一索引可能不是遞增關(guān)系時(例如字符串、UUID、多字段聯(lián)合唯一索引的情況)，該表的存取效率就會比較差。

感謝各位的閱讀！看完上述內(nèi)容，你們對 MySQL 主鍵自增的原因大概了解了嗎？希望文章內(nèi)容對大家有所幫助。如果想了解更多相關(guān)文章內(nèi)容，歡迎關(guān)注丸趣 TV 行業(yè)資訊頻道。

丸趣 TV 網(wǎng) – 提供最優(yōu)質(zhì)的資源集合！