細說 MySQL 與 UUIDs 的問題

因為 UUID 提供低碰撞的隨機性,所以實務上蠻多人會使用 UUID 作為資料表的主鍵(PK),不過使用上要注意一些事:

  1. 使用 VARCHAR 作為儲存 UUID 的資料型態,會佔據較多的記憶體以及儲存空間(storage),資料量小時,我們不會感覺到任何使用上的差異,當資料量大時,這個差異就會顯現出來
  2. UUID 的隨機性容易造成新增資料時 MySQL 需要更新資料表的多個 page ,否則一般 AUTO_INCREMENT 或者 timestamp 作為主鍵的話,只要更新最後一個 page 即可
  3. 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 篇:

GUID/UUID Performance Breakthrough

MySQL & UUIDs

Facebook Threads X

對抗久坐職業傷害

研究指出每天增加 2 小時坐著的時間,會增加大腸癌、心臟疾病、肺癌的風險,也造成肩頸、腰背疼痛等常見問題。

然而對抗這些問題,卻只需要工作時定期休息跟伸展身體即可!

你想輕鬆改變現狀嗎?試試看我們的 PomodoRoll 番茄鐘吧! PomodoRoll 番茄鐘會根據你所設定的專注時間,定期建議你 1 項辦公族適用的伸展運動,幫助你打敗久坐所帶來的傷害!

贊助我們的創作

看完這篇文章了嗎? 休息一下,喝杯咖啡吧!

如果你覺得 MyApollo 有讓你獲得實用的資訊,希望能看到更多的技術分享,邀請你贊助我們一杯咖啡,讓我們有更多的動力與精力繼續提供高品質的文章,感謝你的支持!