核心概念：InnoDB 的雙層數據字典
MySQL 將表結構定義存儲為 .frm 文件，這是所有存儲引擎通用的機制。但 InnoDB 還在表空間內部維護一套數據字典。這意味著：
- 不能直接移動
.frm 文件來遷移 InnoDB 表（需配合表空間數據字典）
DROP TABLE 需同時清理 .frm 與內部字典條目
一、聚簇索引：數據與索引的物理融合
1. 三級降級策略
- 顯式主鍵：
PRIMARY KEY 即為聚簇索引
- 隱式主鍵：首個
NOT NULL UNIQUE 索引升級為聚簇索引
- 合成 RowID：無合適鍵時，InnoDB 內部生成 6 字節單調遞增 RowID 作為隱藏聚簇索引
物理特性：行數據與索引鍵值存放在同一數據頁，B+ 樹葉子節點即為完整行記錄。
2. 性能優勢
- 主鍵查找極快：一次 B+ 樹遍歷直達數據，無需回表
- 範圍掃描高效：葉子節點雙向鏈表，順序讀取無隨機 I/O
- 節省磁盤空間：對比 MyISAM 索引與數據分離，減少重複存儲
二、輔助索引：主鍵值作為「指針」
非聚簇索引葉子節點存儲 索引列值 + 主鍵值。查詢流程：
- 遍歷輔助索引 B+ 樹定位主鍵值
- 攜帶主鍵值回聚簇索引查找完整行
設計啟示：主鍵應盡量短（推薦自增整型），否則輔助索引體積膨脹，間接降低緩存命中率。
三、索引物理結構與頁面管理
- 所有索引均為 B+ 樹，葉子頁存儲記錄
- 默認頁面大小 16 KB
- 插入時預留 1/16 空間（填充因子 ~93.75%）
- 連續插入：頁面填充度 ~15/16
- 隨機插入：填充度 1/2 ~ 15/16
- 填充度 < 1/2 觸發頁合併/樹收縮
四、插入緩衝：將隨機 I/O 轉為順序 I/O
1. 痛點
聚簇索引按主鍵順序插入，屬順序 I/O；輔助索引值分布隨機，導致大量隨機讀寫。
2. 機制
- 目標輔助索引頁在 Buffer Pool 中 → 直接修改
- 不在 Buffer Pool → 寫入 Insert Buffer（內存結構，極小極快）
- 後台線程定期合併：將多次插入合併為一次頁寫入
3. 效果與代價
- 插入性能最高提升 15 倍
- 合併過程持續數小時，期間磁盤 I/O 升高，可能影響查詢性能
- 崩溃恢復/重啟時需完成合併，啟動時間變長
五、實戰優化建議
- 業務主鍵優先用自增 BIGINT，避免 UUID、字符串等長主鍵
- 輔助索引列盡量短，前綴索引（
idx(name(10))）減小體積
- 大批量導數據時：先建表、導數據、再建索引，規避插入緩衝開銷
- 監控指標：
Innodb_buffer_pool_pages_dirty、Innodb_ibuf_merges 觀察合併壓力
