無特殊需求下Innodb建議使用與業(yè)務(wù)無關(guān)的自增ID作為主鍵
InnoDB引擎使用聚集索引感凤，數(shù)據(jù)記錄本身被存于主索引（一顆B+Tree）的葉子節(jié)點(diǎn)上嫡纠。這就要求同一個(gè)葉子節(jié)點(diǎn)內(nèi)（大小為一個(gè)內(nèi)存頁或磁盤頁）的各條數(shù)據(jù)記錄按主鍵順序存放携兵，因此每當(dāng)有一條新的記錄插入時(shí)辅斟，MySQL會(huì)根據(jù)其主鍵將其插入適當(dāng)?shù)墓?jié)點(diǎn)和位置靖诗，如果頁面達(dá)到裝載因子（InnoDB默認(rèn)為15/16），則開辟一個(gè)新的頁（節(jié)點(diǎn)）
1沪斟、如果表使用自增主鍵广辰，那么每次插入新的記錄，記錄就會(huì)順序添加到當(dāng)前索引節(jié)點(diǎn)的后續(xù)位置主之，當(dāng)一頁寫滿择吊，就會(huì)自動(dòng)開辟一個(gè)新的頁。如下圖所示：
這樣就會(huì)形成一個(gè)緊湊的索引結(jié)構(gòu)槽奕，近似順序填滿几睛。由于每次插入時(shí)也不需要移動(dòng)已有數(shù)據(jù)，因此效率很高粤攒，也不會(huì)增加很多開銷在維護(hù)索引上所森。
2、 如果使用非自增主鍵（如果身份證號或?qū)W號等）夯接，由于每次插入主鍵的值近似于隨機(jī)焕济，因此每次新紀(jì)錄都要被插到現(xiàn)有索引頁得中間某個(gè)位置：
此時(shí)MySQL不得不為了將新記錄插到合適位置而移動(dòng)數(shù)據(jù)，甚至目標(biāo)頁面可能已經(jīng)被回寫到磁盤上而從緩存中清掉钻蹬，此時(shí)又要從磁盤上讀回來吼蚁，這增加了很多開銷凭需，同時(shí)頻繁的移動(dòng)问欠、分頁操作造成了大量的碎片，得到了不夠緊湊的索引結(jié)構(gòu)粒蜈，后續(xù)不得不通過OPTIMIZE TABLE來重建表并優(yōu)化填充頁面顺献。
在使用InnoDB存儲(chǔ)引擎時(shí)，如果沒有特別的需要枯怖，請永遠(yuǎn)使用一個(gè)與業(yè)務(wù)無關(guān)的自增字段作為主鍵注整。
mysql 在頻繁的更新、刪除操作度硝，會(huì)產(chǎn)生碎片肿轨。而含碎片比較大的表，查詢效率會(huì)降低蕊程。此時(shí)需對表進(jìn)行優(yōu)化椒袍，這樣才會(huì)使查詢變得更有效率。
innodb如何選擇一個(gè)聚集索引
對于innodb藻茂，主鍵毫無疑問是一個(gè)聚集索引驹暑。但是當(dāng)一個(gè)表沒有主鍵玫恳，或者沒有一個(gè)索引，innodb會(huì)如何處理呢优俘。請看如下規(guī)則
- 如果一個(gè)主鍵被定義了京办，那么這個(gè)主鍵就是作為聚集索引
- 如果沒有主鍵被定義，那么該表的第一個(gè)唯一非空索引被作為聚集索引
- 如果沒有主鍵也沒有合適的唯一索引帆焕，那么innodb內(nèi)部會(huì)生成一個(gè)隱藏的主鍵作為聚集索引惭婿，這個(gè)隱藏的主鍵是一個(gè)6個(gè)字節(jié)的列，該列的值會(huì)隨著數(shù)據(jù)的插入自增叶雹。
還有一個(gè)需要注意的是：
次級索引的葉子節(jié)點(diǎn)并不存儲(chǔ)行數(shù)據(jù)的物理地址审孽。而是存儲(chǔ)的該行的主鍵值。
所以：一次級索引包含了兩次查找浑娜。一次是查找次級索引自身佑力。然后查找主鍵（聚集索引）
