大家好，mysql主鍵用uuid是否合適相信很多的網(wǎng)友都不是很明白，包括mysql主鍵的作用及其特征也是一樣，不過沒有關(guān)系，接下來就來為大家分享關(guān)于mysql主鍵用uuid是否合適和mysql主鍵的作用及其特征的一些知識(shí)點(diǎn)，大家可以關(guān)注收藏，免得下次來找不到哦，下面我們開始吧！

文章目錄：

• 1、為什么不建議用uuid作為主鍵
• 2、使用雪花id或uuid作為Mysql主鍵,被老板懟了一頓!
• 3、mysql我通過程序來生成一個(gè)uuid,做主鍵可行嗎?

為什么不建議用uuid作為主鍵

不能當(dāng)主鍵的原因：MySQL寫入數(shù)據(jù)時(shí)，會(huì)把數(shù)據(jù)存放到索引頁中。MySQL寫入數(shù)據(jù)時(shí)，會(huì)把數(shù)據(jù)存放到索引頁中。使用UUID作為主鍵，新行的主鍵值不一定比之前的主鍵值大，所以innoDb無法做到總是把新行插入到索引的最后，而需要為新行尋找合適的位置來分配新的空間（因?yàn)槭荁+樹方式存儲(chǔ)的）。

不建議UUID作為主鍵的原因主要有以下幾點(diǎn)： **性能問題**：UUID是隨機(jī)生成的，沒有順序性，這會(huì)導(dǎo)致在數(shù)據(jù)庫中進(jìn)行索引時(shí)，數(shù)據(jù)分布不均勻，增加索引碎片，降低查詢效率。特別是在數(shù)據(jù)量大的情況下，UUID作為主鍵的表在插入和刪除數(shù)據(jù)時(shí)，可能會(huì)導(dǎo)致索引的頻繁分裂和重組，進(jìn)一步影響性能。

這在數(shù)據(jù)量龐大的情況下，將導(dǎo)致額外的存儲(chǔ)開銷。其次，UUID值的格式使得調(diào)試變得復(fù)雜。例如，比較UUID值時(shí)需要使用特定的格式，而不是簡(jiǎn)單的整數(shù)比較，這可能增加調(diào)試的難度。最后，由于UUID的大小和無序性，使用UUID可能導(dǎo)致性能問題。

使用雪花id或uuid作為Mysql主鍵,被老板懟了一頓!

為解答此問題，我們構(gòu)建了三張表：ur_auto_key， ur_uuid， ur_random_key。每張表的主鍵采用不同的生成策略，其余字段保持一致，以控制變量法測(cè)試表的插入速度和查詢效率。這里的隨機(jī)key指的是使用雪花算法生成的、前后不連續(xù)、不重復(fù)、無規(guī)律的ID，長(zhǎng)度為18位的long值。

在MySQL中設(shè)計(jì)表時(shí)，推薦不要使用UUID或非連續(xù)非重復(fù)的雪花ID（long型且唯一，單機(jī)遞增），而是推薦使用連續(xù)自增的主鍵ID，即auto_increment。那么為什么不建議使用UUID，使用UUID究竟有哪些壞處呢？本篇博客將分析這個(gè)問題，探討其中的原因。

在MySQL數(shù)據(jù)庫設(shè)計(jì)中，推薦使用自動(dòng)增長(zhǎng)的主鍵（auto_increment）而非UUID或雪花ID作為主鍵。本文將深入探討為何不建議使用UUID，分析其潛在的壞處，并與自增ID進(jìn)行對(duì)比。

在MySQL設(shè)計(jì)中，是否應(yīng)采用UUID或雪花ID作為主鍵，而不是推薦的auto_increment？本文將分析為何不建議使用UUID，以及其帶來的壞處。首先建立三張表，分別是ur_auto_key、ur_uuid、ur_random_key，分別代表自動(dòng)增長(zhǎng)的主鍵、UUID作為主鍵、隨機(jī)key作為主鍵，其他字段保持一致，用于比較插入速度與查詢效率。

首先，我們創(chuàng)建三張表：ur_auto_key、ur_uuid、ur_random_key。它們分別使用自動(dòng)增長(zhǎng)的主鍵、uuid和隨機(jī)key作為主鍵。在相同的環(huán)境中，我們測(cè)試了這三張表的插入速度和查詢速度。使用隨機(jī)key其實(shí)是指使用雪花算法生成的前后不連續(xù)、不重復(fù)、無規(guī)律的ID。我們使用spring的jdbcTemplate實(shí)現(xiàn)程序增查測(cè)試。

在MySQL中設(shè)計(jì)表時(shí)，推薦使用自動(dòng)增長(zhǎng)的主鍵id而非UUID或雪花ID，這是基于建議的auto_increment。那么為何不建議使用UUID？讓我們深入探討原因。為了解釋這一問題，我們創(chuàng)建了三張表：ur_auto_key、ur_uuid和ur_random_key。

mysql我通過程序來生成一個(gè)uuid,做主鍵可行嗎?

1、首先，使用UUID作為主鍵時(shí)，可能會(huì)遇到值的亂序問題。與自增列從1遞增不同，UUID生成的順序并不必然遞增，這可能導(dǎo)致數(shù)據(jù)插入過程中出現(xiàn)性能瓶頸，特別是在高并發(fā)環(huán)境下。這是因?yàn)閿?shù)據(jù)庫在處理亂序數(shù)據(jù)時(shí)，可能會(huì)額外花費(fèi)資源進(jìn)行排序，從而影響插入速度。其次，UUID的存儲(chǔ)空間較大。

2、不能當(dāng)主鍵的原因：MySQL寫入數(shù)據(jù)時(shí)，會(huì)把數(shù)據(jù)存放到索引頁中。MySQL寫入數(shù)據(jù)時(shí)，會(huì)把數(shù)據(jù)存放到索引頁中。使用UUID作為主鍵，新行的主鍵值不一定比之前的主鍵值大，所以innoDb無法做到總是把新行插入到索引的最后，而需要為新行尋找合適的位置來分配新的空間（因?yàn)槭荁+樹方式存儲(chǔ)的）。

3、在MySQL中生成UUID主鍵，可以使用UUID（）函數(shù)。該函數(shù)會(huì)生成一個(gè)標(biāo)準(zhǔn)的UUID字符串，格式為8-4-4-12的十六進(jìn)制數(shù)字和字母組成的字符串。

4、在探討為何面試官不推薦使用UUID作為MySQL主鍵時(shí)，我們首先需要理解UUID在某些場(chǎng)景下的優(yōu)點(diǎn)。UUID值在表、數(shù)據(jù)庫甚至服務(wù)器間具有唯一性，這使得它能夠在合并來自不同數(shù)據(jù)庫的行或跨服務(wù)器分布數(shù)據(jù)庫時(shí)保持一致性。

5、在MySQL數(shù)據(jù)庫設(shè)計(jì)中，盡管UUID和雪花ID常被用作確保數(shù)據(jù)唯一性的手段，但它們并不總是最佳選擇。本文探討了在MySQL中不推薦這些ID作為主鍵的原因，并將它們與自增ID進(jìn)行比較。首先，UUID由于其全球唯一性，常用于分布式，但其36字符的存儲(chǔ)空間占用較大，且隨機(jī)生成導(dǎo)致索引效率低，查詢可能較慢。

好了，文章到此結(jié)束，希望可以幫助到大家。