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

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

規(guī)范

MySQL開發(fā)規(guī)范中經(jīng)?？梢钥吹剑?/p>

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

禁止使用uuid做主鍵

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

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

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

原因

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

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

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

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

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

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

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

隱式主鍵：

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

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

詳解-重點(diǎn)：

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

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

理論總結(jié)：

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

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

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

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

3）減少了頁分裂和碎片的產(chǎn)生

選擇 主鍵id：

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

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

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

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

UUID：

一：使用場景

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

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

所以MySQL8.0也是順應(yīng)時代潮流，擔(dān)負(fù)時代的革命重任，MySQL8.0也對uuid的存儲做了進(jìn)一步的提升。整體上看MySQL8.0現(xiàn)在的重點(diǎn)方向也是對開發(fā)的友好度支持上。

結(jié)論：

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

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

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

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

實戰(zhàn)：

環(huán)境準(zhǔn)備

在MySQL 5.7中分別創(chuàng)建三張數(shù)據(jù)表：

test_varchar：以UUID作為主鍵。

test_long：以bigint作為主鍵。

test_int：以int作為主鍵。

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

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

壓測信息

表類型：InnoDB

數(shù)據(jù)量：100W條

數(shù)據(jù)庫：

主鍵采用uuid 32位

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

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

運(yùn)行查詢語句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()產(chǎn)生數(shù)據(jù)，數(shù)據(jù)為有序列的純數(shù)字（22461015967875697）。（其相當(dāng)于自動增長，只是固定的基數(shù)值較大而已。）

運(yùn)行查詢語句1：

SELECT COUNT(id) FROM test_long;

運(yùn)行查詢語句2：

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

運(yùn)行查詢語句3：

SELECT * FROM test_long WHERE id='22461015967875702';

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

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

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

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

主鍵采用自增int

運(yùn)行查詢語句1：

SELECT COUNT(id) FROM test_int;

運(yùn)行查詢語句2：

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

運(yùn)行查詢語句3：

SELECT * FROM test_int WHERE id=900002;

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

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

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

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

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

新增：

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

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