我孤伶伶地坐在會議室，等著經理進來，心裡七上八下。我被首席產品官（ CPO ）臨時叫去開會。他說會議很緊急、很重要，要我立刻放下手邊工作。

我做產品負責人五個月了，七個月的合約快到期，我不禁擔心起自己的去留。

終於，門開了，他笑咪咪地走進來，我的緊張感瞬間消失。我還記得他說：「咱們公司剛接到史上最大咖的案子！有個刺激的新專案需要你來負責。」

聽到「刺激」和「新」這兩個字，我警鈴大作，心想：「代誌絕對不單純！」

他說：「為了成交，我們跟客戶掛保證，會在 SaaS 產品裡做一些客製化開發。我相信你一定可以準時完成這個關鍵功能，順利簽約。」

啊！陷阱果然在這，我想。

最後，他丟下一句經典名言：「安啦！他們要的功能很簡單啦！」

原來咱們的 CTO 和 CPO 覺得客戶的要求很簡單、很好做，對其他客戶也有幫助。我收到合約裡列出的七個重點，要在 12 週內完成。我沒參與估算，團隊也沒參與。除了這七點，我根本不知道要做什麼。

我馬上開始工作。跟一位資深工程師聊了幾分鐘後，我感到大難臨頭：這鐵定做不完！我很驚訝公司竟然承諾做不到的事。只要隨便問一個工程師就知道根本不可能。高層根本沒問過團隊，就自己用水晶球算時間，然後把這個不可能的任務丟給我們。

現在，要在這麼短的時間內完成，變成我們的問題了。我跟經理說這根本是天方夜譚，他卻回我：「你想得太複雜了啦！簡單一點就好。」

The fortune-telling approach used by management to come up with estimates illustrated by the fantastic Francisco Carle for this article

荒謬的估算從一開始就註定失敗

這七個重點需要十個團隊跨部門合作開發新功能，根本不可能在期限內完成。

光第一個重點就要花兩個月。之後雖然比較好掌握進度，但我敢保證，絕對不可能在 12 週內完成。工作量太大，團隊也太多。更扯的是，估算錯誤不是我的問題，但現在變成我的責任了。

那些搞出這齣爛戲的人只叫我「自己想辦法」、「給我弄出來」。我對合約裡的七個重點有很多疑問，得到的答案卻是：「我沒空理你，你自己看著辦。」

真是的，事情已經夠難了！

我跟客戶第一次開會就老實說做不完。我提議，會提早完成第一個重點，並且積極和他們合作，把他們的回饋納入後續開發，其他部分可能會比較晚完成，等第一個重點完成後，我才能比較精確地評估時間。

還好客戶答應了，雖然他們完全可以照合約走。最後，整個專案花了一年多才完成。還好我們跟客戶保持密切合作，也把他們的期待管理好，所以客戶還算滿意。

我們要怎麼避免這種痛苦的狀況？為什麼估算常常不準？我們要怎麼提高估算的準確度？我們要怎麼把這個必要之惡的傷害降到最低？

開發軟體產品十幾年來，我把我的經驗整理成 11 條軟體估算法則，可以幫助你面對複雜工作，以及軟體估算的複雜現實。

1. 不管估算多準，實際工作時間都一樣

我問你：「這罐子裡有幾個一塊錢？」

你大概猜不準。你甚至不知道罐子有多高。但你猜的數字不會影響罐子裡實際的硬幣數量。現實不會因為你的猜測而改變。

估算專案時程也是一樣的道理。功能開發需要多少時間就是多少時間，跟你的估算無關。是因為我們對時程的期待，才會覺得專案延遲。

2. 估算永遠不可能完全可靠

估算只是猜測。資訊不足的情況下做的預測。處理複雜工作時，我們都知道資訊不足。我們的資訊和理解有限，估得準只是運氣好，就像你光看照片就能猜中罐子裡的硬幣數量一樣。

期望估算很準，就像看茶葉算命一樣。沒有任何資訊，你根本沒辦法預測未來。

所以，不要相信估算。估算是根據你當下掌握的資訊做的，而這些資訊通常不足以讓你對複雜工作做出明確的結論。

不要相信估算，要知道它反映的是你當下的理解，通常是不準確的。但至少是個開始，總比沒有好。

3. 把估算強加在別人身上是自找麻煩

沒有什麼比逼團隊照不準的估算做事更讓人賭爛。估算常常不準，團隊會把氣出在做估算的人身上。

如果你想要團隊配合、做出比較準的估算，就讓實際做事的人自己估。這樣就算估不準，團隊也只能怪自己。

把估算丟給別人，只會造成災難，大家互相指責。

4. 專案快結束時，估算比較準，但也最沒用

專案初期，你掌握的資訊最少，估算也最不準。但這時候你最想知道專案需要多少心力，因為你還可以及時停損。

隨著專案進行，你會更了解狀況，估算也會越來越準。但專案快結束時，估算的準確度已經不重要了。而且因為已經投入這麼多時間和資源，公司不太可能喊停。

但不要被騙了。即使快做完了，還是有可能會冒出一些問題，毀掉整個專案。在軟體開發中，小問題也可能造成很大的影響。

5. 你越擔心估算，就表示你有更重要的事要擔心

估算只是個幌子。很容易讓人分心，以為準確的估算和準時交件最重要。但實際工作時間就是那麼長，跟你的估算無關。

當團隊努力趕上水晶球算出來的不切實際的時程時，就會開始產生隧道效應。就像沙漠中的海市蜃樓，大家只看到眼前的期限。所有討論都圍繞著「怎麼在期限內完成？」，而「品質夠好嗎？」被擺一邊，「怎麼加快速度？」變成最重要的事。

一直執著於「什麼時候可以完成？」只會讓你忽略真正重要的價值交付。

6. 你越不會寫程式，估算就越不準。你越會寫程式，估算頂多普普通通

不管你怎麼做，估算都不可能很準。能不能準確估算跟能不能做出好軟體沒什麼關係。比較厲害的團隊通常估得比較準，但再怎麼準，也不可能完全準確。

就像氣象預報一樣，超過一個禮拜就不準了。軟體開發團隊的估算能力也有極限。

不管你怎麼做，都不可能保證估算很準，也不可能保證準時交件。

7. 估算最大的價值不是估算本身，而是確認大家的理解有沒有共識

估算結果不一樣，通常表示大家對要做的事情理解不同。

透過討論，才能找出彼此認知上的差異。估算最大的價值是建立共識，而不是估算的結果，因為結果常常不準。

8. 保持簡單是提高估算準確度的最佳方法

減少複雜性和不確定性，不管是做事之前或過程中，都是提高估算準確度的最佳方法。保持簡單，才能避免估算失控。但要注意，如果事情過於簡化，也會產生問題。

9. 做比說更能提高估算的準確度

開始做事之前，大家喜歡討論、分析、設計、辯論、做一堆研究，想要消除所有不確定性和風險。但不管你怎麼做，你還是受限於你事先知道的資訊。一直根據不完整的資訊做推論，效果會越來越差。

實際去做，才能更快發現真正重要的問題。

用你已知的去發現你不知道的。

光有理論不夠，還要有實務經驗。

10. 把所有工作拆解到最細，只是讓你更晚交件

為了讓估算更準，我們常常開一堆會，把所有工作拆解到最細。但這樣反而浪費了寶貴的時間，這些時間本來可以拿來做事，找出真正重要的問題。而且這些精密的計畫脫離現實，只會越做越慢。

計畫趕不上變化，硬要照著計畫走是很危險的。最好一開始就做簡單一點的計畫，比較容易調整。你把所有工作拆解到最細，只是讓你更清楚專案會延遲多久而已。

11. 懲罰估算不準，就像處罰小孩不懂的事

有些公司覺得，團隊越成熟、越厲害，估算就會越準。所以估不準的團隊就是爛團隊。

懲罰團隊估不準，是在懲罰他們無法控制的事情。就像處罰小孩不懂的事情一樣。這是一種霸凌，只會造成恐慌和焦慮，沒有任何好處。

別再幻想你可以做出準確的估算

總之，以下是「複雜工作軟體估算的 11 條法則」：

1. 不管估算多準，實際工作時間都一樣。

2. 估算永遠不可能完全可靠。

3. 把估算強加在別人身上是自找麻煩。

4. 專案快結束時，估算比較準，但也最沒用。

5. 你越擔心估算，就表示你有更重要的事要擔心。

6. 你越不會寫程式，估算就越不準。你越會寫程式，估算頂多普普通通。

7. 估算最大的價值不是估算本身，而是確認大家的理解有沒有共識。

8. 保持簡單是提高估算準確度的最佳方法。

9. 做比說更能提高估算的準確度。

10. 把所有工作拆解到最細，只是讓你更晚交件。

11. 懲罰估算不準，就像處罰小孩不懂的事。

過去的表現不能保證未來的結果，尤其在軟體估算方面。 1943 年，美國一家賭場，紅色連贏 32 次。你很容易就會覺得有什麼規律，但這是典型的「賭徒謬誤」：

「沒辦法理解機率事件的獨立性，誤以為可以根據過去的結果預測未來的結果。」 — APA 字典定義

很多軟體團隊都犯了同樣的錯誤，我稱之為「複雜工作估算謬誤」：

「誤以為只要常常估算、大家一起討論很久，就可以做出準確的估算。」— Maarten Dalmijn 提出的複雜工作估算謬誤

不管你怎麼做，估算都不可能很準。不要再自欺欺人了。

問問自己：你真的需要精確預測事情何時完成嗎？如果你確定自己正盡全力做出有價值的東西，就算比預期慢一點又怎樣？那個預期本來就不準。

調整你的方向，應對突發狀況和不確定性，而不是抱怨你永遠無法預測和控制的風向。

我鮮少預測科技發展，但這點我很肯定：幾十年後，能寫作的人將大幅減少。身為寫作者，你會發現許多人其實不太會寫。醫生知道有多少人擔心自己的痣；電腦高手知道有多少人對電腦一竅不通；寫作者則知道有多少人需要寫作協助。

寫作困難是許多人struggle的主因。寫得好，必須思考清晰，而清晰思考並非易事。然而，寫作卻充斥許多工作，職位越高階，寫作要求也越高。

寫作的普遍需求和寫作的難度，兩股力量相互拉扯，形成巨大壓力。這也是為何知名教授會抄襲的原因。這些案例最令人訝異的是抄襲內容的平庸，通常只是一些制式內容，任何稍具寫作能力的人都能輕鬆完成，這表示他們根本不具備基本寫作能力。

直到不久前，人們還找不到舒緩這種壓力的方法。你可以像甘迺迪一樣花錢請人代筆，或像金恩博士一樣抄襲。但如果既不能買也不能偷，就只能自己寫。因此，幾乎所有被期待會寫作的人都必須學習寫作。

現在不同了，AI 的出現徹底改變了遊戲規則。寫作壓力幾乎煙消雲散，無論學業或職場，都能仰賴 AI 代勞。

結果就是世界將一分為二：會寫和不會寫的人。仍然會有人能寫，有些人甚至樂在其中。但寫作好手和完全不會寫的人之間的灰色地帶將會消失。以往有高手、普通人和完全不會寫的人，未來只剩下高手和不會寫的人。

這樣不好嗎？科技淘汰技能，導致某些技能消失，不是很常見嗎？現在鐵匠很少見了，也沒造成太大問題。

不，這很糟，因為寫作就是思考。有些思考只能透過寫作完成。正如 Leslie Lamport 所言：

不寫而思，只是自以為在思考。

因此，寫作能力的兩極分化比聽起來更危險，這將造成思考能力的兩極分化。我知道我想屬於哪一邊，你應該也是。

這種情況並非史無前例。工業時代前，多數人的工作需要勞力，自然練就一身好體格。現在想變壯，得去健身房。所以還是有壯漢，但僅限於那些主動鍛鍊的人。

寫作也一樣。未來還是有聰明人，但僅限於那些主動思考的人。

感謝 Jessica Livingston、Ben Miller 和 Robert Morris 協助審閱本文草稿。

用唯一識別碼（UUID）的設計宗旨是讓開發者在不了解其他系統的情況下，以確保唯一性的方式產生獨特的 ID。這在分散式架構中特別有用，因為你可能有多個負責建立記錄的系統和資料庫。你或許認為在資料庫中使用 UUID 作為主鍵是個好主意，但若使用不當，可能會嚴重影響資料庫效能。

本文將探討在 MySQL 資料庫中使用 UUID 作為主鍵的缺點。

UUID 的多個版本

截至撰寫本文時，共有五個正式版本的 UUID 和三個草案版本。讓我們逐一檢視每個版本，以更了解它們的運作方式。

UUIDv1

UUID 第 1 版稱為基於時間戳記的 UUID，可以拆解如下：

雖然現代計算大多使用 UNIX 紀元時間（1970 年 1 月 1 日）作為基準，但 UUID 實際上使用不同的日期：1582 年 10 月 15 日，這是格里高利曆開始被廣泛使用的日期。UUID 中嵌入的時間戳記從這個日期開始以 100 奈秒為單位遞增，然後用於設定 UUID 的 time_low、time_mid 和 time_hi 部分。

UUID 的第三部分包含 version，以及佔據該部分第一個字元的 time_hi。所有版本的 UUID 皆是如此，後續範例也會說明。reserved 部分也稱為 UUID 的變體，它決定了 UUID 中位元的用途。最後一部分是 node，即產生 UUID 的系統的唯一位址。

UUIDv2

與版本 1 相比，UUID 版本 2 的 time_low 部分被 POSIX 使用者 ID 取代。理論上，這些 UUID 可以追溯到產生它們的使用者 ID。由於 time_low 部分是 UUID 中變化最大的部分，取代這個部分會增加碰撞的機率。因此，這個版本的 UUID 很少使用。

UUIDv3 和 UUIDv5

版本 3 和版本 5 非常相似。這些版本的目標是允許以確定性的方式產生 UUID，讓相同的資訊能產生相同的 UUID。這些實作使用兩個資訊：命名空間（本身是一個 UUID）和名稱。這些值會透過雜湊演算法運算，以產生可表示為 UUID 的 128 位元值。

這兩個版本的主要差異在於版本 3 使用 MD5 雜湊演算法，而版本 5 使用 SHA1。

UUIDv4

版本 4 稱為隨機變體，因為它的值幾乎完全是隨機的。唯一的例外是 UUID 第三部分的第一個位置，它永遠是 4，表示使用的版本。

UUIDv6

版本 6 與版本 1 幾乎相同。唯一的差異是用於記錄時間戳記的位元被反轉，這代表時間戳記的最重要部分會先儲存。下圖顯示了這些差異：

這樣做的主要目的是建立與版本 1 相容的值，同時讓這些值更容易排序，因為時間戳記的最重要部分在前面。

UUIDv7

版本 7 也是基於時間戳記的 UUID 變體，但它整合了更常用的 Unix 紀元時間戳記，而不是版本 1 使用的格里高利曆日期。另一個主要區別是，節點（基於產生 UUID 的系統的值）被隨機性取代，讓這些 UUID 更難追溯到來源。

UUIDv8

版本 8 是最新版本，允許特定供應商的實作同時遵守 RFC 標準。UUIDv8 的唯一要求是版本必須在第三部分的第一個位置指定，就像所有其他版本一樣。

UUID 和 MySQL

使用 UUID（大多數情況下）可以保證架構中所有系統的唯一性，因此你可能會傾向將它們用作記錄的主鍵。但請注意，相較於自動遞增整數，這樣做有一些取捨。

插入效能

每次將新記錄插入 MySQL 表格時，都需要更新與主鍵相關的索引，以提升查詢表格的效能。MySQL 中的索引採用 B 樹形式，這是一種多層資料結構，允許查詢快速找到所需的資料。

下圖顯示了一個包含六個條目（值從 1 到 6）的簡化版本。如果查詢需要 5，MySQL 會從根節點開始，然後知道必須遍歷樹的右側才能找到目標。

💡

為了簡化說明，這些圖表顯示的是 B 樹而不是 B+ 樹。主要區別在於 B 樹的葉節點包含對實際資料的參考，而 B+ 樹則不包含。

如果新增 7 到 9，MySQL 會分割右節點並重新平衡樹狀結構。

這個過程稱為頁面分割，目的是保持 B 樹結構平衡，讓 MySQL 能快速找到資料。對於連續值，這個過程相對簡單；然而，當演算法中引入隨機性時，MySQL 重新平衡樹狀結構可能需要更長時間。在高負載資料庫中，這可能會影響使用者體驗，因為 MySQL 會嘗試保持樹狀結構的平衡。

💡

有關 B 樹運作方式的更多資訊，我們在 MySQL for Developers 課程中有專門的影片。

更高的儲存利用率

MySQL 中的所有主鍵都會建立索引。預設情況下，自動遞增整數的每個值會佔用 32 位元的儲存空間。相較之下，如果以緊湊的二進位格式儲存，單個 UUID 在磁碟上會佔用 128 位元，是 32 位元整數的 4 倍。如果選擇使用更易讀的基於字串的表示法，每個 UUID 可以儲存為 CHAR(36)，每個 UUID 佔用高達 288 位元，是 32 位元整數的 9 倍。

除了主鍵上建立的預設索引外，次要索引也會佔用更多空間。這是因為次要索引使用主鍵作為指向實際資料列的指標，這表示它們需要與索引一起儲存。根據使用 UUID 作為主鍵的表格上建立的索引數量，這可能會導致資料庫的儲存需求顯著增加。

最後，頁面分割（如前節所述）也可能對儲存空間使用率造成負面影響，同時影響效能。InnoDB 假設主鍵會以可預測的方式遞增，無論是數值或字典順序。如果是這樣，InnoDB 會將頁面填滿到頁面大小的約 94% 才建立新頁面。當主鍵是隨機的時，每個頁面使用的空間可能低至 50%。因此，使用包含隨機性的 UUID 可能導致過度使用頁面來儲存索引。

在 MySQL 中使用 UUID 主鍵的最佳實務

如果必須使用 UUID 作為表格中記錄的唯一識別碼，可以參考以下幾個最佳實務，以盡量減少負面影響。

使用二進位資料類型

雖然 UUID 有時以 36 個字元的字串形式儲存，但它們也可以用原生二進位格式表示。如果轉換為二進位值，可以將其儲存在 BINARY(16) 欄位中，將每個值的儲存需求減少到 16 位元組。這仍然比 32 位元整數大得多，但肯定比將 UUID 儲存為 CHAR(36) 要好。

create table uuids(
  UUIDAsChar char(36) not null,
  UUIDAsBinary binary(16) not null
);


insert into uuids set
  UUIDAsChar = 'd211ca18-d389-11ee-a506-0242ac120002',
  UUIDAsBinary = UUID_TO_BIN('d211ca18-d389-11ee-a506-0242ac120002');


select * from uuids;
-- +--------------------------------------+------------------------------------+
-- | UUIDAsChar                           | UUIDAsBinary                       |
-- +--------------------------------------+------------------------------------+
-- | d211ca18-d389-11ee-a506-0242ac120002 | 0xD211CA18D38911EEA5060242AC120002 |
-- +--------------------------------------+------------------------------------+

使用有序的 UUID 變體

使用支援排序的 UUID 版本可以減輕使用 UUID 的部分效能和儲存空間影響，因為產生的值更連續，避免了前面提到的部分頁面分割問題。即使在多個系統上產生，基於時間戳記的 UUID（例如版本 6 或版本 7）也能保證唯一性，同時保持值盡可能接近連續。UUIDv1 例外，因為它的時間戳記最不重要的部分在前面。

使用 MySQL 內建的 UUID

MySQL 直接支援在 SQL 中產生 UUID；然而，它只支援 UUIDv1 值。雖然單獨使用它們並非最佳做法，但 MySQL 有一個輔助函式 uuid_to_bin。這個函式不僅會將字串值轉換為二進位，你還可以搭配使用 swap flag 選項，它會重新排列時間戳記部分，讓產生的二進位值更連續。

set @uuidvar = 'd211ca18-d389-11ee-a506-0242ac120002';
-- Without swap flag
SELECT HEX(UUID_TO_BIN(@uuidvar)) as UUIDAsHex;
-- +----------------------------------+
-- | UUIDAsHex                        |
-- +----------------------------------+
-- | D211CA18D38911EEA5060242AC120002 |
-- +----------------------------------+


-- With swap flag
SELECT HEX(UUID_TO_BIN(@uuidvar,1)) as UUIDAsHex;
-- +----------------------------------+
-- | UUIDAsHex                        |
-- +----------------------------------+
-- | 11EED389D211CA18A5060242AC120002 |
-- +----------------------------------+

使用替代 ID 類型

UUID 並非唯一一種在分散式架構中提供唯一性的識別碼類型。考量到它們最初創建於 1987 年，其他專家已經提出不同的格式，例如 Snowflake ID、ULID，甚至是 NanoID（我們在 PlanetScale 使用）。

# Snowflake ID
7167350074945572864


# ULID
01HQF2QXSW5EFKRC2YYCEXZK0N


# NanoID
kw2c0khavhql

結論

在 MySQL 中使用 UUID 主鍵可以（幾乎）保證分散式系統中的唯一性；然而，它也伴隨著一些取捨。幸運的是，有許多版本和替代方案可供選擇，你可以選擇更能解決這些取捨的方案。閱讀本文後，你應該能夠在設計下一個資料庫時做出更明智的決策，選擇適合你的 ID 類型。

多年來，Medium 工程團隊 (與人資團隊合作) 持續精進評估工程師成長和影響力的流程。 我們先前分享過一些心得，很高興其他公司也採用類似模式！

隨著我們不斷學習，現在已經是這個流程的第三次迭代，我們很興奮能與這個社群分享一些重要的心得。Medium 的核心任務是打造最好的產品，所以雖然我們不會在每次迭代成長框架時都更新這篇文章，但我們仍然持續討身為一個工程師的成長意義、領導者的職責擴展，以及如何公平評估。

以下要點概述了我們如何不斷改進流程，以建立一個強大、靈活且包容的團隊：

• 評估準則應著重可觀察、教導和評估的行為。

• 持續溝通成長和影響力，評估時不該有驚喜。

• 研究顯示，加薪的快樂很短暫，長久的滿足來自個人發展。 這也是我們聚焦成長的原因。

• 我們重視成長型思維，並體現在評估準則中。

• 統評估方法（階梯、職位、框架等）主要在於分級。 我們建立以個人成長為中心的架構，支持理想職涯發展，並同時讓公司受益。 我們以成長為核心，用評量準則定義進步、衡量和獎勵。

• 成功的評估系統，應公平對待並獎勵員工，不因個人特徵而有差異。

• 好的評量準則能激勵團隊，並認可不同人的價值。

• 招募和成長應與公司價值觀連結，獎勵我們重視的特質。

• 成功的職涯有很多路，多元的經驗和優勢讓團隊更強大。

• 職稱的目的：了解進步、賦予權力，以及對外溝通能力水平。

• 執行力：好點子需要好執行。 團隊開發軟體，需要凝聚共識、技術領導、注重品質和有效溝通。

• 好的管理才能充分發揮團隊、展望未來，並在變革中穩定軍心。

• 理想的評估完全客觀，對任務做是非判斷。 雖然很難，但要盡力。 主觀易有偏見，要確保公平。

• 如何客觀評估溝通？如何評估無私？

• 我們的標準基於影響範圍，展現技能如何影響更多人或層面。

在經歷這個過程的過程中，我們學到了很多，感謝我們的社群就這個話題提出的問題和進行的對話！

Buildkite 過去用兩個鍵值儲存資料。我們用循序主鍵來有效索引，也用 UUID 次要鍵值供外部使用。即將到來的 UUIDv7 標準兩者兼具；它按時間排序的 UUID 主鍵可同時用於索引和外部使用。本文將帶您了解 Buildkite 如何決定採用 UUIDv7 作為主鍵。我們會探討資料庫索引的取捨：從循序整數、隨機 UUID，到時間識別碼。

什麼是 UUID？

UUID（通用唯一識別碼）是不需中央機構或與其他方協調就能獨立產生的唯一識別碼。隨著大型現代應用程式和系統的分布式特性，UUID 格式的識別碼越來越常被用作資料庫鍵值。不像循序整數識別碼需要協調才能在分布式資料庫中確保全局唯一性，UUID 免除了協調的負擔，讓它在分片資料庫環境中更受歡迎。

UUID 也比循序整數識別碼更有優勢。UUID 不可預測，能公開使用而不洩露敏感內部資訊和統計數據。UUID 也難以猜測，除了存取控制檢查外，還能多一層防護，防止「不安全的直接物件參考」( Insecure Direct Object Reference ) 漏洞。

UUID 的隨機性和 128 位元的長度讓重複的機率趨近於零，所以我們可以認為 UUID「實際上」是唯一的。然而，標準非時間排序 UUID（例如 v4）的隨機性，如果用作主鍵，可能會造成資料庫效能問題。這問題常被稱為「資料庫索引局部性差」。

使用雙重識別碼

幾年前，因為非時間排序 UUID 效能問題很大，我們決定標準化使用循序整數 ID 作為主鍵。我們也在資料庫表格上使用 UUID 作為次要識別碼。涉及表格聯結的查詢會使用循序整數外鍵，通常比隨機 UUID 外鍵效能更好。外部和面向客戶的部分都使用 UUID（例如在 API 和網址中）。所有團隊都標準化這種雙重識別碼方法，以提升工程師生產力。

了解索引局部性差的問題

連續產生的非時間排序 UUID 值不是循序的。隨機產生的值不會在資料庫索引中聚集，所以插入會在隨機位置執行。這種隨機插入會影響 B 樹等常見索引資料結構及其變體的效能。

Buildkite 產品的特性代表最近的資料比舊資料存取更頻繁。用非循序識別碼時，最新資料會隨機分散在索引中，缺乏聚集性。所以，從大型資料集擷取最新資料需要遍歷很多資料庫索引頁面，導致快取命中率低（快取成功滿足的請求數和收到的請求數相比）。相反地，用循序識別碼時，最新資料會按邏輯排列在索引最右邊，對快取更友善。

改進 UUID 的運作方式

索引局部性問題在過去十多年來產生許多實作方式。常見的解決方案是使用基於時間的唯一識別碼。識別碼的第一部分（前綴）是可排序的時間戳記，讓這些識別碼能按循序（和聚集）順序插入索引資料結構。因為產生的識別碼是循序的，所以插入效能和插入循序整數識別碼差不多。

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          time stamp         | |               random                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

根據實作方式，識別碼的其餘部分可以完全隨機產生，也可以是機器循序並用機器／分片編號編碼。例如 ULID、Instagram 的 ShardingID、Twitter 的 Snowflake 和 Mastodon 修改版的 Snowflake。

實驗基於時間戳記的 UUIDv4

2022 年，一個新的依時間排序的 UUID 標準提案開始受到關注，UUIDv7 規範成為 RFC 網際網路草案。

當時，Buildkite 開始試用與 UUIDv4 相容的依時間排序 UUID。

• 前 48 位元（原本是隨機的）變成時間戳記。

• 版本位元維持不變，讓依時間排序的 UUID 可以被視為一般的 UUIDv4 值。

• 維持 v4 相容性對某些 Buildkite 客戶很重要。實驗中，Buildkite 嘗試將版本設為「7」，卻發現這會讓一些驗證 UUID 但還不了解 UUIDv7 的下游客戶系統出錯。

這個改變（以及 6 週內其他幾項改變）讓主要資料庫的 WAL（預寫式日誌）速率降低了 50%。寫入 IO 也降低了。WAL 速率降低讓團隊能輕鬆設定讀取副本和執行其他資料庫遷移任務。

介紹 UUID 版本 7

UUID 版本 7（UUIDv7）是依時間排序的 UUID，它以毫秒精度將 Unix 時間戳記編碼到最重要的 48 位元。和所有 UUID 格式一樣，用 6 位元表示 UUID 版本和變體。其餘 74 位元是隨機產生的。因為 UUIDv7 依時間排序，所以產生的值實際上是循序的，也就解決了索引局部性問題。

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           unix_ts_ms                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          unix_ts_ms           |  ver  |       rand_a          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |var|                        rand_b                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            rand_b                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

UUIDv7 依時間排序的特性，讓它的資料庫效能比隨機前綴的 UUIDv4 好很多。 2nd quadrant 部落格的一篇文章比較了隨機 UUID 和循序 UUID，顯示寫入和讀取效能都有提升。

UUIDv7 繼續遵循標準 UUID 格式，所以實際上可以把它們當作其他 UUID 使用。這項相容性讓我們可以使用現有的 Postgres UUID 欄位，輕鬆地將欄位從儲存 UUIDv4 值轉換為 UUIDv7。

遷移到 UUIDv7 作為主鍵

今年初，我們決定在新表格中使用 UUIDv7 作為主鍵（取代循序整數 ID）。

Buildkite 工程師目前正依組織 ID 將 Pipelines 資料庫分片。我們很快發現，在分布式資料庫環境中，使用整數 ID 作為主鍵會變成負擔。在資料庫之間確保遞增整數主鍵唯一性，協調和解決方法都不理想。隨著 UUIDv7 標準穩定且接近定稿，Buildkite 決定在新表格中使用 UUIDv7 作為主鍵。

使用 UUIDv7 作為主鍵就不需為新表格協調識別碼產生。我們也不用第二個整數識別碼欄位，簡化了應用程式邏輯。這些 UUID 可以在 API 中外部使用，也可以內部用作外鍵。

考慮的替代方案和權衡

我們團隊考慮過很多方法，包括 Instagram 的 ShardingID 實作和 Shopify 的複合主鍵實作，我們也考慮保留我們自己訂製的依時間排序 UUIDv4。但是，我們研究的方法都很新穎，可能很複雜，加上 UUIDv7 很可能成為未來的標準，所以我們決定用 UUIDv7。

UUID 有 128 位元，是其他 64 位元方案的兩倍長。雖然有一些額外的儲存空間開銷，但相較於資料庫列其他部分的儲存空間，以及遷移的好處，這點開銷對我們來說很小。

展望未來

Buildkite 目前正依組織 ID 將 Pipelines 資料庫分片。目前我們不需要將資料庫分片編號編碼到識別碼。但值得一提的是，如果未來需要，UUIDv8（大致允許任何內容）可以用來將分片編號加到識別碼中。

新的 UUID RFC 正在最後審查階段，我期待 UUIDv7 成為 IETF 提議標準。