細說 MySQL 與 UUIDs 的問題
覺得我們的內容實用嗎？ MyApollo 電子報讀者募集中！歡迎訂閱電子報!
因為 UUID 提供低碰撞的隨機性，所以實務上蠻多人會使用 UUID 作為資料表的主鍵(PK)，不過使用上要注意一些事：
- 使用 VARCHAR 作為儲存 UUID 的資料型態，會佔據較多的記憶體以及儲存空間(storage)，資料量小時，我們不會感覺到任何使用上的差異，當資料量大時，這個差異就會顯現出來
- UUID 的隨機性容易造成新增資料時 MySQL 需要更新資料表的多個 page ，否則一般 AUTO_INCREMENT 或者 timestamp 作為主鍵的話，只要更新最後一個 page 即可
- MySQL 使用的是 v1 版本的 UUID，產生時會參考 timestamp ，所以經常可以看到 UUID 有些部分沒有變動，這是由於它們都在相近時間產生的緣故，這也導致 MySQL 在做索引(index)時的效率會不佳
這些問題可以將主鍵資料型態改為 Binary(16) 以及呼叫 UUID_TO_BIN(UUID(), 1) 產生 UUID 的 Binary 進行改善，其中 UUID_TO_BIN 的第 2 個參數是將 timestamp 的 low field 與 high field 對換，其實就是讓變動較快的 bits 排在前面，避免 UUID 一直產生相同的部分。
詳細文章可以參考以下 2 篇：
