被勸退后三月中旬到現在無 offer，問我如何設計一個高性能MySQL 主鍵，實現海量數據下的高效查詢
在脈脈上有一個熱度很高的帖子「碩 1.5，被勸退后三月中旬到現在無 offer，不知道怎么破」。
圖片
有網友說：「如果能約到面試，說明簡歷不差，但是 50 場都沒有 offer，說明你的面試談判技巧出現了問題，應該總結一下，及時調整，心態不要崩」。
圖片
由這個話題為引子，碼哥接下來給你分享一個知識點：「如何設計一個高性能MySQL 主鍵，實現海量數據下的高效查詢」。
為什么需要主鍵
三個點。
- 數據記錄需具有唯一性(第一范式)
- 數據需要關聯 join。
- 數據庫底層索引用于檢索數據所需數據。
為什么主鍵不宜過長
這個問題的點在長上。那短比長有什么優勢？（嘿嘿嘿，內涵）—— 短不占空間。
但這么點磁盤空間相對整個數據量來說微不足道。
那么原因應該在快上，而且和原始數據關系不大。以此自然得出和索引相關，而且和索引讀取相關。那么為什么主鍵過大在索引中會影響性能？
圖片
圖中是 MySQL Innodb 引擎的索引數據結構。
左邊是聚簇索引，通過主鍵定位數據記錄。
右邊是普通索引，對列數據做索引，通過列數據查找數據主鍵。
如果通過普通查詢數據，流程如圖所示，先從普通索引樹上搜索到主鍵，然后在聚簇索引上通過主鍵搜索到數據行。
其中普通索引的葉子節點是直接存儲的主鍵值，而不是主鍵指針。
所以如果主鍵太長，一個普通索引樹所能存儲的索引記錄就會變少，這樣在有限的索引緩沖中，需要讀取磁盤的次數就會變多，所以性能就會下降。
為什么建議使用遞增 ID
圖片
InnoDB 使用聚簇索引，如上圖所示，數據記錄本身被存于索引（一顆 B+Tree）的葉子節點上有序存儲。
這就要求同一個葉子節點內（大小為一個內存頁或磁盤頁）的各條數據記錄按主鍵順序存放。
因此每當有一條新的記錄插入時，MySQL 會根據其主鍵值將其插入適當的節點和位置，如果頁面達到裝載因子（InnoDB 默認為 15/16），則開辟一個新的頁（節點）。
如果表使用自增主鍵，那么每次插入新的記錄，記錄就會順序添加到當前索引節點的后續位置，當一頁寫滿，就會自動開辟一個新的頁。這樣就會形成一個緊湊的索引結構，近似順序填滿。
由于每次插入時也不需要移動已有數據，因此效率很高，也不會增加很多開銷在維護索引上，如下圖所示。
否則由于每次插入主鍵的值近似于隨機，因此每次新記錄都要被插到現有索引頁的中間某個位置，MySQL 不得不為了將新記錄插到合適位置而移動數據，如下圖右側所示。
圖片
ID 是否有需要具備業務含義
業務 ID，即使用具有業務意義的 id，比如使用訂單流水號作為訂單表的主鍵 Key。
邏輯 ID，即無關業務的 id，按某種規則生成 id，如自增 ID。
業務 ID 的優點
- ID 具有業務意義，在查詢時可以直接作為搜索關鍵字使用。
- 不需要額外的列和索引空間。
- 可以減少一些 join 操作。
業務 ID 的缺點
- 當業務發生變化時，有時需要變更主鍵。
- 涉及多列 ID 時比較難操作。
- 業務 ID 往往比較長，所占空間更大，導致更大的磁盤 I/O。
- 在 ID 確定前不能持久化數據，有時我們沒有在確定數據 ID 。時，就想先添加一條記錄，之后再更新業務 ID。
- 設計一個兼具易用和性能的 ID 生成方案比較難。
邏輯 ID 的優點
- 不會因為業務的變動而需要修改 ID 邏輯。
- 操作簡單，且易于管理。
- 邏輯 ID 往往更小，性能更優。
- 邏輯 ID 更容易保證唯一性。
- 更易于優化。
邏輯 ID 的缺點
- 查詢主鍵列和主鍵索引需要額外的磁盤空間。
- 在插入數據和更新數據時需要額外的 I/O。
- 更多的 join 可能。
- 如果沒有唯一性策略限制，容易出現重復的 ID。
- 測試環境和正式環境 ID 不一致，不利于排查問題。
- ID 的值沒有和數據關聯，不符合三范式。
- 不能用于搜索關鍵字。
- 依賴不同數據庫系統的具體實現，不利于底層數據庫的替換。
主鍵 ID 生成方式有哪些？
一般情況下，我們都使用 MySQL 的自增 ID，來作為表的主鍵，這樣簡單，而且從上面講到的來看，性能也是最好的。
但是在分庫分表的情況情況下，自增 ID 則不能滿足需求。我們可以來看看不同數據庫生成 ID 的方式，也看一些分布式 ID 生成方案。
MySQL 自增
MySQL 在內存中維護一個自增計數器，每次訪問 auto-increment 計數器的時候， InnoDB 都會加上一個名為AUTO-INC 鎖直到該語句結束(注意鎖只持有到語句結束,不是事務結束)。
AUTO-INC 鎖是一個特殊的表級別的鎖，用來提升包含 auto_increment 列的并發插入性。
在分布式的情況下，其實可以獨立一個服務和數據庫來做 ID 生成，依舊依賴 MySQL 的表 ID 自增能力來為第三方服務統一生成 id。
Mongodb ObjectId
Mongodb 為防止主鍵沖突，設計了一個 ObjectId 作為主鍵 id。它由一個 12 字節的十六進制數字組成，其中包含以下幾部分：
- Time：時間戳。4 字節。秒級。
- Machine：機器標識。3 字節。一般是機器主機名的散列值，這樣就確保了不同主機生成不同的機器 hash 值，確保在分布式中不造成沖突，同一臺機器的值相同。
- PID：進程 ID。2 字節。上面的 Machine 是為了確保在不同機器產生的 objectId 不沖突，而 pid 就是為了在同一臺機器不同的 mongodb 進程產生的 objectId 不沖突。
- INC：自增計數器。3 字節。前面的九個字節保證了一秒內不同機器不同進程生成的 objectId 不沖突，自增計數器，用來確保在同一秒內產生的 objectId 也不會發現沖突，允許 256 的 3 次方等于 16777216 條記錄的唯一性。
開源框架實現
- 百度 UidGenerator：基于snowflake算法。
- 美團 Leaf：同時實現了基于 MySQL 自增（優化）和 snowflake 算法的機制。
博主簡介
碼哥，9 年互聯網公司后端工作經驗，InfoQ 簽約作者、51CTO Top 紅人，阿里云開發者社區專家博主，目前擔任后端架構師主責，擅長 Redis、Spring、Kafka、MySQL 技術和云原生微服務。
