您好,登錄后才能下訂單哦!
Mysql中主鍵UUID和自增主鍵有什么區(qū)別?針對(duì)這個(gè)問題,這篇文章詳細(xì)介紹了相對(duì)應(yīng)的分析和解答,希望可以幫助更多想解決這個(gè)問題的小伙伴找到更簡(jiǎn)單易行的方法。
1. 避免重復(fù),便于scale,這就是我們做cloud service的時(shí)候選擇uuid的主要原因
2. 入庫(kù)之前可以知道id
3.相對(duì)安全,不能簡(jiǎn)單的從uuid獲取信息,但是如果自增,則容易暴露信息,如果一個(gè)客戶id是123456,很容易猜到有客戶id是123456.
1.uuid有16個(gè)字節(jié),比int(4 byte)和bigint(8 byte)占用更多存儲(chǔ)空間
2.由于size和無序性,可能引起性能問題
mysql的innodb存儲(chǔ)引擎處理storage的方式是靠聚集索引。
聚集索引是指數(shù)據(jù)庫(kù)表行中數(shù)據(jù)的物理順序與鍵值的邏輯(索引)順序相同。一個(gè)表只能有一個(gè)聚集索引,因?yàn)橐粋€(gè)表的物理順序只有一種情況
(1).其實(shí)在innodb存儲(chǔ)引擎下,自增長(zhǎng)的id做主鍵性能已經(jīng)達(dá)到了最佳。不論是存儲(chǔ)和讀取速度都是最快的,而且占的存儲(chǔ)空間也是最小。
(2).但是在我們實(shí)際到項(xiàng)目中會(huì)碰到問題,歷史數(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ù)操作很有好處,可以說一勞永逸。
缺點(diǎn): 1. 影響插入速度, 并且造成硬盤使用率低
2. uuid之間比較大小相對(duì)數(shù)字慢不少, 影響查詢速度。
3. uuid占空間大, 如果你建的索引越多, 影響越嚴(yán)重
優(yōu)點(diǎn):出現(xiàn)數(shù)據(jù)拆分、合并存儲(chǔ)的時(shí)候,能達(dá)到全局的唯一性
(1).InnoDB引擎表是基于B+樹的索引組織表。
(2).B+樹:B+樹是為磁盤或其他直接存取輔助設(shè)備而設(shè)計(jì)的一種平衡查找樹,在B+樹中,所有記錄節(jié)點(diǎn)都是按鍵值的大小順序存放在同一層的葉節(jié)點(diǎn)中,各葉節(jié)點(diǎn)指針進(jìn)行連接。
(3).InnoDB主索引:葉節(jié)點(diǎn)包含了完整的數(shù)據(jù)記錄。這種索引叫做聚集索引。InnoDB 的索引能提供一種非??焖俚闹麈I查找性能。不過,它的輔助索引也會(huì)包含主鍵列,所以,如果主鍵定義的比較大,其他索引也將很大。如果想在表上定義 、很多索引,則爭(zhēng)取盡量把主鍵定義得小一些。InnoDB 不會(huì)壓縮索引
(4).聚集索引這種實(shí)現(xiàn)方式使得按主鍵的搜索十分高效,但是輔助索引搜索需要檢索兩遍索引:首先檢索輔助索引獲得主鍵,然后用主鍵到主索引中檢索獲得記錄。
綜合上述可得:
(1).如果InnoDB表的數(shù)據(jù)寫入順序能和B+樹索引的葉子節(jié)點(diǎn)順序一致的話,這時(shí)候存取效率是最高的。為了存儲(chǔ)和查詢性能應(yīng)該使用自增長(zhǎng)id做主鍵。
(2).對(duì)于InnoDB的主索引,數(shù)據(jù)會(huì)按照主鍵進(jìn)行排序,由于UUID的無序性,InnoDB會(huì)產(chǎn)生巨大的IO壓力,此時(shí)不適合使用UUID做物理主鍵,可以把它作為邏輯主鍵,物理主鍵依然使用自增ID。為了全局的唯一性,應(yīng)該用uuid做索引關(guān)聯(lián)其他表或做外鍵。
如果是主從即M-S模式,最好是不使用mysql自帶函數(shù)uuid來生成唯一主鍵,因?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ù)
mysql使用了navicat客戶端,某次執(zhí)行了如下sql
select replace(uuid(), '-', '') as id, u.user_id from t_user u;
結(jié)果發(fā)現(xiàn),生成的uuid重復(fù)了,
經(jīng)過排查,發(fā)現(xiàn)是navicat的問題,需要將該sql語(yǔ)句做如下調(diào)整:
select replace(convert(uuid() using utf8mb4), '-', ''), u.user_id from t_user u;
結(jié)果如下:
將uuid再進(jìn)行一次md5:
select md5(uuid()) as id, u.user_id from t_user u;
關(guān)于Mysql中主鍵UUID和自增主鍵有什么區(qū)別問題的解答就分享到這里了,希望以上內(nèi)容可以對(duì)大家有一定的幫助,如果你還有很多疑惑沒有解開,可以關(guān)注億速云行業(yè)資訊頻道了解更多相關(guān)知識(shí)。
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。