Mysql中主鍵UUID和自增主鍵有什么區(qū)別？針對(duì)這個(gè)問(wèn)題，這篇文章詳細(xì)介紹了相對(duì)應(yīng)的分析和解答，希望可以幫助更多想解決這個(gè)問(wèn)題的小伙伴找到更簡(jiǎn)單易行的方法。

創(chuàng)新互聯(lián)公司是一家集網(wǎng)站建設(shè),鹽城企業(yè)網(wǎng)站建設(shè),鹽城品牌網(wǎng)站建設(shè),網(wǎng)站定制,鹽城網(wǎng)站建設(shè)報(bào)價(jià),網(wǎng)絡(luò)營(yíng)銷(xiāo),網(wǎng)絡(luò)優(yōu)化,鹽城網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強(qiáng)企業(yè)競(jìng)爭(zhēng)力?？沙浞譂M(mǎn)足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時(shí)我們時(shí)刻保持專(zhuān)業(yè)、時(shí)尚、前沿，時(shí)刻以成就客戶(hù)成長(zhǎng)自我，堅(jiān)持不斷學(xué)習(xí)、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實(shí)用型網(wǎng)站。

什么情況下我們希望用uuid

1. 避免重復(fù)，便于scale，這就是我們做cloud service的時(shí)候選擇uuid的主要原因

2. 入庫(kù)之前可以知道id

3.相對(duì)安全，不能簡(jiǎn)單的從uuid獲取信息，但是如果自增，則容易暴露信息，如果一個(gè)客戶(hù)id是123456，很容易猜到有客戶(hù)id是123456.

UUID有什么問(wèn)題

1.uuid有16個(gè)字節(jié)，比int（4 byte）和bigint（8 byte）占用更多存儲(chǔ)空間

2.由于size和無(wú)序性，可能引起性能問(wèn)題

Mysql的uuid原理

mysql的innodb存儲(chǔ)引擎處理storage的方式是靠聚集索引。

聚集索引是指數(shù)據(jù)庫(kù)表行中數(shù)據(jù)的物理順序與鍵值的邏輯（索引）順序相同。一個(gè)表只能有一個(gè)聚集索引，因?yàn)橐粋€(gè)表的物理順序只有一種情況

1.為什么要使用uuid做主鍵

(1).其實(shí)在innodb存儲(chǔ)引擎下，自增長(zhǎng)的id做主鍵性能已經(jīng)達(dá)到了很好。不論是存儲(chǔ)和讀取速度都是最快的，而且占的存儲(chǔ)空間也是最小。

(2).但是在我們實(shí)際到項(xiàng)目中會(huì)碰到問(wèn)題，歷史數(shù)據(jù)表的主鍵id會(huì)與數(shù)據(jù)表的id重復(fù)，兩張自增id做主鍵的表合并時(shí)，id一定會(huì)有沖突，但如果各自的id還關(guān)聯(lián)了其他表，這就很不好操作。

(3).如果使用UUID，生成的ID不僅是表獨(dú)立的，而且是庫(kù)獨(dú)立的。對(duì)以后的數(shù)據(jù)操作很有好處，可以說(shuō)一勞永逸。

2.UUID優(yōu)缺點(diǎn)

缺點(diǎn)： 1. 影響插入速度， 并且造成硬盤(pán)使用率低

2. uuid之間比較大小相對(duì)數(shù)字慢不少， 影響查詢(xún)速度。

3. uuid占空間大， 如果你建的索引越多， 影響越嚴(yán)重

優(yōu)點(diǎn)：出現(xiàn)數(shù)據(jù)拆分、合并存儲(chǔ)的時(shí)候，能達(dá)到全局的性

3.最優(yōu)方案

(1).InnoDB引擎表是基于B+樹(shù)的索引組織表。

(2).B+樹(shù)：B+樹(shù)是為磁盤(pán)或其他直接存取輔助設(shè)備而設(shè)計(jì)的一種平衡查找樹(shù)，在B+樹(shù)中，所有記錄節(jié)點(diǎn)都是按鍵值的大小順序存放在同一層的葉節(jié)點(diǎn)中，各葉節(jié)點(diǎn)指針進(jìn)行連接。

(3).InnoDB主索引：葉節(jié)點(diǎn)包含了完整的數(shù)據(jù)記錄。這種索引叫做聚集索引。InnoDB 的索引能提供一種非常快速的主鍵查找性能。不過(guò)，它的輔助索引也會(huì)包含主鍵列，所以，如果主鍵定義的比較大，其他索引也將很大。如果想在表上定義 、很多索引，則爭(zhēng)取盡量把主鍵定義得小一些。InnoDB 不會(huì)壓縮索引

(4).聚集索引這種實(shí)現(xiàn)方式使得按主鍵的搜索十分高效，但是輔助索引搜索需要檢索兩遍索引：首先檢索輔助索引獲得主鍵，然后用主鍵到主索引中檢索獲得記錄。

綜合上述可得：

(1).如果InnoDB表的數(shù)據(jù)寫(xiě)入順序能和B+樹(shù)索引的葉子節(jié)點(diǎn)順序一致的話，這時(shí)候存取效率是高的。為了存儲(chǔ)和查詢(xún)性能應(yīng)該使用自增長(zhǎng)id做主鍵。

(2).對(duì)于InnoDB的主索引，數(shù)據(jù)會(huì)按照主鍵進(jìn)行排序，由于UUID的無(wú)序性，InnoDB會(huì)產(chǎn)生巨大的IO壓力，此時(shí)不適合使用UUID做物理主鍵，可以把它作為邏輯主鍵，物理主鍵依然使用自增ID。為了全局的性，應(yīng)該用uuid做索引關(guān)聯(lián)其他表或做外鍵。

4.如果非要使用uuid做主鍵，下面是小建議：

如果是主從即M-S模式，好是不使用mysql自帶函數(shù)uuid來(lái)生成主鍵，因?yàn)橹鞅砩傻膗uid要再關(guān)聯(lián)從表時(shí)，需要再去數(shù)據(jù)庫(kù)查出這個(gè)uuid，需要多進(jìn)行一次數(shù)據(jù)庫(kù)交互，而且在這個(gè)時(shí)間差里面主表很有可能還有數(shù)據(jù)生成，這樣就很容易導(dǎo)致關(guān)聯(lián)的uuid出錯(cuò)。如果真要使用uuid，可以在Java中生成后，直接存儲(chǔ)到DB里，這時(shí)主從的uuid就是一樣的了！

補(bǔ)充：mysql的uuid()主鍵重復(fù)

1、mysql的uuid()主鍵重復(fù)

mysql使用了navicat客戶(hù)端，某次執(zhí)行了如下sql

select replace(uuid(), '-', '') as id, u.user_id from t_user u;

結(jié)果發(fā)現(xiàn)，生成的uuid重復(fù)了，

經(jīng)過(guò)排查，發(fā)現(xiàn)是navicat的問(wèn)題，需要將該sql語(yǔ)句做如下調(diào)整:

select replace(convert(uuid() using utf8mb4), '-', ''), u.user_id from t_user u;

結(jié)果如下：

2、使用其他方案：

將uuid再進(jìn)行一次md5：

select md5(uuid()) as id, u.user_id from t_user u;

關(guān)于Mysql中主鍵UUID和自增主鍵有什么區(qū)別問(wèn)題的解答就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，如果你還有很多疑惑沒(méi)有解開(kāi)，可以關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道了解更多相關(guān)知識(shí)。

本文題目：Mysql中主鍵UUID和自增主鍵有什么區(qū)別-創(chuàng)新互聯(lián)
URL分享：http://www.rwnh.cn/article42/cehdec.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供定制開(kāi)發(fā)、服務(wù)器托管、App設(shè)計(jì)、企業(yè)建站、移動(dòng)網(wǎng)站建設(shè)、網(wǎng)站設(shè)計(jì)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶(hù)投稿、用戶(hù)轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)