對 UUID 主鍵使用字符串類型與 uuid 類型相比，對性能有何影響？

Question

使用string作為主鍵與實際uuid類型的索引查找速度是否有很大差異，特別是如果字符串具有像user-94a942de-05d3-481c-9e0c-da319eb69206 （使得查找必須遍歷 5 -6 個字符才能獲得獨特的東西）？

Answer 1

這是一種微觀優化，在你達到巨大的規模之前不太可能導致真正的性能問題。 使用最適合您設計的鑰匙。 那就是說，這里的細節......

UUID是內置的PostgreSQL類型 。 它基本上是一個128位整數。 它應該像任何其他大整數一樣作為索引執行。 Postgres沒有內置的UUID生成功能。 您可以在數據庫上安裝各種模塊，也可以在客戶端上執行。 在客戶端上生成UUID會將額外的工作（沒有太多額外工作）分散到服務器之外。

MySQL沒有內置的UUID類型。 相反，有一個UUID函數可以生成UUID作為十六進制數字的字符串。 因為它是一個字符串，UUID鍵可能會有性能和存儲命中。 它也可能會干擾復制。

字符串UUID會更長; 十六進制字符每字節僅編碼4位數據，因此十六進制字符串UUID需要256位來存儲128位信息。 這意味着每列更多的存儲和內存會影響性能。

通常這意味着比較的時間是兩倍，因為比較的密鑰是兩倍長。 但是，UUID在前幾個字節中通常是唯一的，因此不需要比較整個UUID就知道它們是不同的。 簡而言之：比較字符串與二進制UUID不應該在實際應用程序中引起明顯的性能差異......盡管MySQL UUID是UTF8編碼的事實可能會增加成本。

在PostgreSQL上使用UUID很好，它是一個內置類型。 MySQL的UUID密鑰實現非常不完整，我會遠離它。 當你在它的時候，遠離MySQL。

Answer 2

當表（或至少索引）太大而無法緩存在RAM中時，UUID的真正問題就出現了。 當發生這種情況時，需要將“下一個”uuid存儲到一些不太可能被緩存的隨機塊中（或從中獲取）。 隨着表的增長，這會導致越來越多的I / O.

AUTO_INCREMENT ids 通常不會遭受I / O增長，因為INSERTs總是位於表的“結尾”，而SELECTs 通常會在結尾附近聚集。 這導致有效使用高速緩存，從而避免了死亡。

我的UUID博客討論了如何使“Type-1”UUID的性能成本降低，至少對MySQL來說如此。

Answer 3

使用映射到 128 位 int 的內置 UUID 類型。 不僅僅是為了性能，也是為了防止像“password1”這樣的字符串出現在該列中。