MySql主鍵id不推薦使用UUID的原因是什么

本文小編為大家詳細介紹“MySql主鍵id不推薦使用UUID的原因是什么”，內容詳細，步驟清晰，細節處理妥當，希望這篇“MySql主鍵id不推薦使用UUID的原因是什么”文章能幫助大家解決疑惑，下面跟著小編的思路慢慢深入，一起來學習新知識吧。

規范

MySQL開發規范中經常可以看到：

推薦使用int,bigint 無符號做自增鍵

禁止使用uuid做主鍵

關于主鍵的類型選擇上最常見的爭論是用整型還是字符型的問題，關于這個問題《高性能MySQL》一書中有明確論斷：

整數通常是標識列的最好選擇，因為它很快且可以使用AUTO_INCREAMENT,如果可能，應該避免使用字符串類型作為標識列，因為很消耗空間，且通常比數字類型慢。

如果是使用MyISAM，則就更不能用字符型，因為MyISAM默認會對字符型采用壓縮引擎，從而導致查詢變得非常慢。

原因

通常主鍵 id 的數據類型有兩種選擇：字符串或者整數，主鍵通常要求是唯一的，如果使用字符串類型，我們可以選擇 UUID 或者具有業務含義的字符串來作為主鍵。

對于 UUID 而言，它由 32 個字符+4 個’-'組成，長度為 36，雖然 UUID 能保證唯一性，但是它有兩個致命的缺點：

1.不是遞增的。MySQL 中索引的數據結構是 B+Tree，這種數據結構的特點是索引樹上的節點的數據是有序的，而如果使用 UUID 作為主鍵，那么每次插入數據時，因為無法保證每次產生的 UUID 有序，所以就會出現新的 UUID 需要插入到索引樹的中間去，這樣可能會頻繁地導致頁分裂，使性能下降。

2.太占用內存。每個 UUID 由 36 個字符組成，在字符串進行比較時，需要從前往后比較，字符串越長，性能越差。另外字符串越長，占用的內存越大，由于頁的大小是固定的，這樣一個頁上能存放的關鍵字數量就會越少，這樣最終就會導致索引樹的高度越大，在索引搜索的時候，發生的磁盤 IO 次數越多，性能越差。

對于整數的數字類型，MySQL 中主要有 int 和 bigint 類型。其中 int 占用 4 個字節，bigint 占用 8 個字節，這和 Java 中的 int 和 long 對應。如果使用無符號的 int 類型作為主鍵，那么主鍵的最大值為 2^32-1，即 4294967295，這個值不到 43 億，似乎有點太小了。雖然一張表的數據，我們不可能讓其達到 43 億條（太大會影響性能），但是對于頻繁進行插入、刪除的表來說，43 億這個值是可以達到的。而如果使用無符號的 bigint 類型的話，主鍵的最大值可以達到 2^64-1，這個數足夠大了，如果以每秒插入 100 萬條數據計算的，58 萬年以后才能達到最大值。所以 bigint 作為主鍵的數據類型，完全不用擔心超過最大值的問題。

而強制要求主鍵 id 是自增的，則是為了在數據插入的過程中，盡可能的避免索引樹上頁分裂的問題。

關于主鍵是聚簇索引，如果沒有主鍵，InnoDB會選擇一個唯一鍵來作為聚簇索引，如果沒有唯一鍵，會生成一個隱式的主鍵。

隱式主鍵：

InnoDB會自動幫你創建一個不可見的、長度為6字節的row_id，而且InnoDB維護了一個全局的dictsys.row_id，所有未定義主鍵的表都會共享該row_id，每次插入一條數據都把全局row_id當成主鍵id，然后全局row_id加1。

該全局row_id在代碼實現上使用的是bigint unsigned類型，但實際上只給row_id保留了6字節，所以這種設計就會存在一個問題：如果全局row_id一直漲，直到2的48次冪-1時，這個時候再加1，row_id的低48位都會變為0，如果再插入新一行數據時，拿到的row_id就為0，這樣的話就存在主鍵沖突的可能，所以為了避免這種隱患，每個表都需要一個主鍵。

詳解-重點：

InnoDB引擎使用聚集索引，數據記錄本身被存于主索引（一顆B+Tree）的葉子節點上。這就要求同一個葉子節點內（大小為一個內存頁或磁盤頁）的各條數據記錄按主鍵順序存放，因此每當有一條新的記錄插入時，MySQL 會根據其主鍵將其插入適當的節點和位置，如果頁面達到裝載因子（InnoDB默認為15/16），則開辟一個新的頁（節點）

所以在使用innoDB表時要避免隨機的（不連續且值的分布范圍非常大）聚簇索引，特別是針對I/O密集型的應用。例如：從性能角度考慮，使用UUID的方案就會導致聚簇索引的插入變得完全隨機。

理論總結：

自增的主鍵的值是順序的，所以 Innodb 把每一條記錄都存儲在一條記錄的后面。

當達到頁面的最大填充因子時候 ( innodb默認的最大填充因子是頁大小的15/16，會留出1/16的空間留作以后的修改)：

1）下一條記錄就會寫入新的頁中，一旦數據按照這種順序的方式加載，主鍵頁就會近乎于順序的記錄填滿，提升了頁面的最大填充率，不會有頁的浪費

2）新插入的行一定會在原有的最大數據行下一行,mysql定位和尋址很快，不會為計算新行的位置而做出額外的消耗

3）減少了頁分裂和碎片的產生

選擇 主鍵id：

tinyint、smallint、mediumint，這三個不常用就不說了。無符號是設置了 unsigned 屬性，表示不允許負值，這大致可以使正數的上限提高一倍。

以無符號int類型為例，42億雖然看起來是個很大的數字，但是對于一些插入刪除很頻繁的業務來說，并非無法觸達這個上限。特別是有的業務表設置的步長比較大，會導致id自增的速度更快。如果你的業務預期會產生很多數據，那么建議你在創建表時，直接使用bigint。

因為MySQL的主鍵策略：id自增值達到上限以后，再申請下一個 id 時，仍然是最大值。

如果bigint真的還不夠使用的話，我們可以使用雪花算法生成的id做主鍵，由于其也是大致遞增的，對性能也不會產生影響，只需要由bigint改成更大范圍的decimal就行。

UUID：

一：使用場景

UUID是指在一臺機器上生成的數字，它保證對在同一時空中的所有機器都是唯一的。在UUID的算法中，可能會用到諸如網卡MAC地址，IP，主機名，進程ID等信息以保證其獨立性

二：有的開發就是喜歡使用UUID怎么辦？

所以MySQL8.0也是順應時代潮流，擔負時代的革命重任，MySQL8.0也對uuid的存儲做了進一步的提升。整體上看MySQL8.0現在的重點方向也是對開發的友好度支持上。

結論：

在MySQL8.0中還是推薦使用無符號的int, bigint做主鍵，如果要使用uuid可以建一個唯一索引

MySQL和Java兩者默認生成的uuid是version 1格式:datetime|mac地址，因為高低位順序亂了，造成順序亂掉，可以使用MySQL的函數uuid_to_bin(@uuid,1) , bin_to_uuid(@uuid,1)進行調整轉換，實現有序化

對于使用uuid_to_bin轉化后的uuid存儲，使用binary(16)或是varbinary(16)替代varchar(36)，從而實現從36byte降到16byte。

這個技巧不是萬能的，如果你的數據庫CPU是瓶頸,使用轉化存儲，可能帶來CPU上更重的開銷，反之，如果你的IO是瓶頸，但CPU有較大的空閑，使用這個技巧就是一個不錯的優化方案。如果不好把握，就用你可以用得到的最好硬件就可以了，一般情況下如果用上SSD后IO都沒啥問題，但也可以使用這個技術去降低表的物理大小。

實戰：

環境準備

在MySQL 5.7中分別創建三張數據表：

test_varchar：以UUID作為主鍵。

test_long：以bigint作為主鍵。

test_int：以int作為主鍵。

三個表的字段，除了主鍵ID 分別采用varchar，bigint 和自動增長int不同外，其他三個字段都為 varchar 36位

另外，建表時使用InnoDB存儲引擎，并且向數據庫中插入100W條數據，用以測試。

壓測信息

表類型：InnoDB

數據量：100W條

數據庫：

主鍵采用uuid 32位

運行查詢語句1：
SELECT COUNT(id) FROM test_varchar;

運行查詢語句2：
SELECT * FROM test_varchar WHERE vname='71e88bab-2f0f-6811-89ff-4cc935c075d8';

運行查詢語句3：

SELECT * FROM test_varchar WHERE id='00004599b05211e196aa002655b28d7b';

三條查詢語句的耗時分別如下所示：

語句1消耗時間平均為：2.81秒；

語句2消耗時間平均為：3.11秒；

語句3消耗時間平均為：0秒；（多方測試，條件里只要有主鍵ID，查詢速度毫秒級都顯示000。測試的ID值，有前一百條的，也有后90多萬條的。查詢時間完全一樣，毫秒級都為000）

主鍵采用bigint

主鍵采用bigint，使用uuid_short()產生數據，數據為有序列的純數字（22461015967875697）。（其相當于自動增長，只是固定的基數值較大而已。）

運行查詢語句1：

SELECT COUNT(id) FROM test_long;

運行查詢語句2：

SELECT * FROM test_long WHERE vname='63b10f80-0e20-28cc-3078-d7331ba410b6';

運行查詢語句3：

SELECT * FROM test_long WHERE id='22461015967875702';

三條查詢語句的耗時分別如下所示：

語句1消耗時間平均為：1.31秒；

語句2消耗時間平均為：1.51秒；

語句3消耗時間平均為：0秒；（多方測試，條件里只要有主鍵ID，查詢速度毫秒級都顯示000。測試的ID值，有前一百條的，也有后90多萬條的。查詢時間完全一樣，毫秒級都為000）

主鍵采用自增int

運行查詢語句1：

SELECT COUNT(id) FROM test_int;

運行查詢語句2：

SELECT * FROM test_int WHERE vname='908b57a5-cdef-32d1-0320-e14209b08894';

運行查詢語句3：

SELECT * FROM test_int WHERE id=900002;

其中，主鍵采用mysql自帶的自動增長，數據為純數字（1，2，3，4，5……）。

三條查詢語句的耗時分別如下所示：

查詢語句1消耗時間平均為：1.20秒；

查詢語句2消耗時間平均為：1.41秒;

查詢語句3消耗時間平均為：0秒；（多方測試，條件里只要有主鍵ID，查詢速度毫秒級都顯示000。測試的ID值，有前一百條的，也有后90多萬條的。查詢時間完全一樣，毫秒級都為000）

新增：

UUID做主鍵，其他字段相同，插入100萬條數據，用了2.5個小時
自增主鍵，其他字段相同，插入相同的100萬條數據，用了26分鐘

讀到這里，這篇“MySql主鍵id不推薦使用UUID的原因是什么”文章已經介紹完畢，想要掌握這篇文章的知識點還需要大家自己動手實踐使用過才能領會，如果想了解更多相關內容的文章，歡迎關注億速云行業資訊頻道。