2019 年 Percona 對 UUID 當作 Primary Key 的看法
source link: https://blog.gslin.org/archives/2021/08/21/10285/2019-%e5%b9%b4-percona-%e5%b0%8d-uuid-%e7%95%b6%e4%bd%9c-primary-key-%e7%9a%84%e7%9c%8b%e6%b3%95/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
2019 年 Percona 對 UUID 當作 Primary Key 的看法
前陣子的「為資料庫提案新的 UUID 格式」這邊提到了有人提案要增加新的 UUID 格式，Percona 的老大 Peter Zaitsev 在 Twitter 上貼了「UUIDs are Popular, but Bad for Performance — Let’s Discuss」這篇在 2019 年時他們家的文章，題到了 MySQL 使用 UUID 當作 Primary Key 的事情：
UUIDs are Popular, but Bad for Performance — Let’s Discuss
https://t.co/2ulSGPB77L— Peter Zaitsev (@PeterZaitsev) August 21, 2021
要注意的是這篇文章沒有要從頭解釋 UUID 對於 Primary Key 的壞處，如果你想要先了解的話，在這篇文章的開頭給了一堆其他文章的連結，裡面就有討論過了。
這篇主要是在討論，如果硬要用 UUID 當 Primary Key 時，可以有什麼方法降低對 InnoDB 的衝擊，剛好回應最近的提案。
開頭還是先花了一些篇幅大概講一下 UUID 的種類，然後在「What is so Wrong with UUID Values?」這邊提到了字串比較的差異，如果 UUID 是到最後一碼才不同的話 (這邊是跑 df878007-80da-11e9-93dd-00163e000002 與 df878007-80da-11e9-93dd-00163e000003 與比較一億次)：
1 row in set (27.67 sec)
但如果是一開始就不同的話 (這邊是選擇 df878007-80da-11e9-93dd-00163e000002 與 ef878007-80da-11e9-93dd-00163e000003) 會快很多：
1 row in set (2.45 sec)
但如果與數字相比的話 (這邊是 2=3 這樣的條件去比)：
1 row in set (0.96 sec)
可以看數字在這邊的優勢，另外也是在說明，如果你用的是 time-based ordering 的 UUID，要考慮會遇到這個可能會發生的效能問題。
再來是玩 UUID 的三種不同的儲存方式對於寫入效能的差異，分別是 CHAR(36) (32 bytes 的 hex 加上四個 -)、base64 (用 CHAR(22) 存) 與 BINARY(16)，可以看出來 BINARY(16) 因為佔用空間比較小的關係，是可以高速寫入持續最久的，再來是 base64，最差的是 CHAR(36)：
後面給了兩個 workaround，第一個算是定義了另外一種產生 128 bits 的方式，第二個則是想辦法把 UUID 對應到數字。
這在 MySQL 的環境裡面算是被討論的很久的主題了。(我猜在 PostgreSQL 應該也是，不過 PostgreSQL 的社群沒跟那麼久...)
Related
為資料庫提案新的 UUID 格式
前幾天在 Hacker News Daily 上看到的東西，今年四月的時候有人針對資料庫提案新的 UUID 格式：「New UUID Formats – IETF Draft (ietf.org)」。 在 draft 開頭有說明這個提案的目標： This document presents new time-based UUID formats which are suited for use as a database key. A common case for modern applications is to create a unique identifier for use as a primary key…
August 14, 2021In "Computer"
用 InnoDB 時關於 PRIMARY KEY 的建議
Percona 的「InnoDB scalability issues due to tables without primary keys」這篇文章在討論 InnoDB 在沒有 PRIMARY KEY 時的效能問題。 在討論效能問題前，應該先讀過 MySQL 官方文件裡提到 InnoDB index 架構的文章，其中就有提到 PRIMARY KEY 以及其他的 INDEX KEY 的底層架構：「InnoDB Table and Index Structures」。 InnoDB 是 clustered index 架構 (關於 clustered index 的完整說明，可以參考維基百科的「Database index」條目)，也就是說，資料本身 (row data) 存放時會按照某個順序存放，這邊的順序是按照這樣的方式定義的： 如果你有指定 PRIMARY KEY，那麼就會直接用 PRIMARY KEY 當作…
October 20, 2013In "Computer"
InnoDB 對 Primary Key 的選擇
前幾天 Ant 在「淺入淺出 MySQL & PostgreSQL」剛好有提到，結果 Percona 這兩天也丟出了這個題目，不過這邊討論的是空間的問題：「Illustrating Primary Key models in InnoDB and their impact on disk usage」。 一樣的作法，Primary Key 的選擇有三種： INT + AUTO_INCREMENT BINARY(16) (Ordered UUID) CHAR(36) (Random UUID) 用的是 Jeremy Cole 的 space-lsn-age-illustrate 畫出 LSN 的值 (InnoDB 的 Log Sequence Number，由於嚴格遞增，可以藉由這個值知道每個 page 最新被修改的時間)： I then used the…
April 4, 2015In "Computer"
Author Gea-Suan LinPosted on August 21, 2021Categories Computer, Database, Murmuring, MySQL, Programming, SoftwareTags base64, binary, char, database, db, hex, index, key, mysql, performance, primary, rdbms, speed, storage, unique, uuid Leave a Reply Cancel reply
Your email address will not be published. Required fields are marked *
Comment
Name *
Email *
Website
Notify me of follow-up comments by email.
Notify me of new posts by email.
Post navigation
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK