日韩欧美人妻无码精品白浆,www.大香蕉久久网,狠狠的日狠狠的操,日本好好热在线观看

最近，公司剛剛開(kāi)了一個(gè)新項(xiàng)目，研發(fā)丟過(guò)來(lái)的建表語(yǔ)句，一看全都是uuid做主鍵。。。

頭大，想要研發(fā)改成自增id，結(jié)果研發(fā)來(lái)一句，自增id不利于數(shù)據(jù)安全。

對(duì)于一個(gè)對(duì)數(shù)據(jù)安全要求高的公司來(lái)說(shuō)，這一句秒殺了。

但是，此題還得解。

本期就說(shuō)說(shuō)自增id和uuid的優(yōu)劣，以及最后的解決方案。

核心要點(diǎn)

1. 為什么用自增ID

2. 自增ID的優(yōu)缺點(diǎn)

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

4. 解決方案

5. 總結(jié)

為什么用自增ID

為什么DBA總是強(qiáng)調(diào)要用自增id做主鍵？

這也是研發(fā)同學(xué)一直以來(lái)的疑問(wèn)，一般DBA會(huì)說(shuō)基于性能考慮。具體為什么，可能也沒(méi)詳細(xì)解釋過(guò)。今天，簡(jiǎn)單明了地解釋一下。

MySQL數(shù)據(jù)如何存儲(chǔ)：

clustered index

The InnoDB term for a primary key index. InnoDB table storage is organized based on the values of the primary key columns, to speed up queries and sorts involving the primary key columns. For best performance, choose the primary key columns carefully based on the most performance-critical queries. Because modifying the columns of the clustered index is an expensive operation, choose primary columns that are rarely or never updated.

In the Oracle Database product, this type of table is known as an index-organized table.

首先，

官方手冊(cè)中關(guān)于聚集索引有詳細(xì)的說(shuō)明

InnoDB表存儲(chǔ)基于主鍵列的值進(jìn)行組織

這類(lèi)表又稱(chēng)之為索引組織表

總結(jié)一句話(huà)就是：MySQL的innodb表的數(shù)據(jù)是按照主鍵的順序進(jìn)行存儲(chǔ)的。

其次，

MySQL數(shù)據(jù)庫(kù)在磁盤(pán)上按數(shù)據(jù)頁(yè)進(jìn)行存儲(chǔ)的，每個(gè)數(shù)據(jù)頁(yè)的默認(rèn)大小為16k

有序主鍵和無(wú)序主鍵的區(qū)別：

1. 有序主鍵（例如自增ID）

存儲(chǔ)性能：

• 插入數(shù)據(jù)：由于自增ID的連續(xù)性，新記錄總是插入到索引的最后位置，符合B+樹(shù)的增長(zhǎng)方式。無(wú)需在中間位置插入或移動(dòng)數(shù)據(jù)，因此插入過(guò)程簡(jiǎn)單，性能較高。

• 數(shù)據(jù)頁(yè)分裂：因數(shù)據(jù)是順序插入的，頁(yè)分裂發(fā)生頻率低。只有在數(shù)據(jù)頁(yè)完全填滿(mǎn)時(shí)才會(huì)新開(kāi)數(shù)據(jù)頁(yè)，以支持新的連續(xù)數(shù)據(jù)，避免了大量的數(shù)據(jù)重排和移動(dòng)。

查詢(xún)性能：

• 順序插入的數(shù)據(jù)在物理上是連續(xù)存儲(chǔ)的，因此基于主鍵的范圍查詢(xún)效率較高，減少了磁盤(pán)隨機(jī)讀寫(xiě)的次數(shù)。尤其是大范圍查詢(xún)時(shí)，數(shù)據(jù)連續(xù)分布在少數(shù)數(shù)據(jù)頁(yè)中，可以減少I(mǎi)O操作。

2. 無(wú)序主鍵（例如UUID）

存儲(chǔ)性能：

• 插入數(shù)據(jù)：UUID是隨機(jī)生成的無(wú)序字符串，新插入數(shù)據(jù)無(wú)法確定插入位置，通常會(huì)插入到B+樹(shù)的中間位置。每次插入都可能導(dǎo)致頁(yè)分裂并重新組織索引，增加了數(shù)據(jù)重排的次數(shù)，導(dǎo)致存儲(chǔ)開(kāi)銷(xiāo)更大。

• 數(shù)據(jù)頁(yè)分裂：由于無(wú)序主鍵的隨機(jī)性，數(shù)據(jù)插入分布不規(guī)律，頁(yè)分裂頻繁。當(dāng)數(shù)據(jù)頁(yè)滿(mǎn)了時(shí)，系統(tǒng)會(huì)強(qiáng)制在中間位置插入新頁(yè)，使得一部分記錄被移動(dòng)到新頁(yè)。頁(yè)分裂和數(shù)據(jù)移動(dòng)會(huì)導(dǎo)致數(shù)據(jù)頁(yè)利用率降低，影響插入性能。

查詢(xún)性能：

• 數(shù)據(jù)分布在更多的非連續(xù)數(shù)據(jù)頁(yè)中，影響了范圍查詢(xún)的效率。每次查詢(xún)需要在多個(gè)不相鄰的數(shù)據(jù)頁(yè)中獲取數(shù)據(jù)，磁盤(pán)的隨機(jī)讀寫(xiě)增加，導(dǎo)致查詢(xún)性能下降。

自增ID的優(yōu)缺點(diǎn)

優(yōu)點(diǎn)：

• 唯一性：每個(gè)記錄的自增ID是唯一的，能夠滿(mǎn)足主鍵的唯一性要求。

• 順序性：自增ID是連續(xù)遞增的整數(shù)值，在插入時(shí)順序排列，不會(huì)引起頻繁的頁(yè)分裂。

• 索引構(gòu)建和維護(hù)成本低：因?yàn)樽栽鯥D按順序增長(zhǎng)，InnoDB在插入數(shù)據(jù)時(shí)無(wú)需頻繁調(diào)整數(shù)據(jù)位置，索引維護(hù)成本較低，性能較高。

• 占用空間小：相比UUID等字符串類(lèi)型的主鍵，自增ID通常是4字節(jié)或8字節(jié)整數(shù)，占用空間更少。

缺點(diǎn)：

• 存在業(yè)務(wù)數(shù)據(jù)泄露風(fēng)險(xiǎn)：連續(xù)的ID可能會(huì)讓人推測(cè)出插入的總數(shù)量或增長(zhǎng)規(guī)律，可能導(dǎo)致數(shù)據(jù)泄露風(fēng)險(xiǎn)。

• 跨庫(kù)合并復(fù)雜：如果不同數(shù)據(jù)庫(kù)或分片中使用相同自增ID策略，數(shù)據(jù)合并時(shí)容易產(chǎn)生沖突。

• 無(wú)法保證全局唯一：自增ID通常是數(shù)據(jù)庫(kù)實(shí)例內(nèi)部唯一，難以在分布式環(huán)境下保證全球唯一性。

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

優(yōu)點(diǎn)：

• 全局唯一性：UUID能夠在分布式系統(tǒng)中保證唯一性，而無(wú)需依賴(lài)中心化的ID生成服務(wù)。

• 支持分布式環(huán)境：在分布式架構(gòu)中，UUID特別適合用于跨數(shù)據(jù)庫(kù)實(shí)例的記錄合并，不會(huì)引起主鍵沖突。

• 數(shù)據(jù)遷移靈活性：數(shù)據(jù)遷移、跨系統(tǒng)整合等操作更簡(jiǎn)單，不需要重新生成主鍵或做ID映射。

• 避免信息泄露：UUID的隨機(jī)性避免了可能會(huì)暴露插入的順序或數(shù)量這一風(fēng)險(xiǎn)，增強(qiáng)了數(shù)據(jù)的安全性。

缺點(diǎn)：

• 插入性能低：UUID是無(wú)序的隨機(jī)字符串，在B+樹(shù)等結(jié)構(gòu)中不能按順序插入，導(dǎo)致頻繁的頁(yè)分裂，增加了數(shù)據(jù)庫(kù)索引的維護(hù)開(kāi)銷(xiāo)，影響插入性能。

• 占用存儲(chǔ)空間大：UUID通常為128位的字符串，存儲(chǔ)時(shí)比自增整數(shù)（4字節(jié)或8字節(jié)）更占用空間。

• 查詢(xún)性能差：因?yàn)閁UID是無(wú)序的，基于UUID的范圍查詢(xún)性能低。UUID在數(shù)據(jù)頁(yè)中分布分散，導(dǎo)致更多的磁盤(pán)隨機(jī)讀取，而不是連續(xù)讀取，增加了IO負(fù)擔(dān)。

• 排序和對(duì)比成本高：UUID長(zhǎng)度較長(zhǎng)，進(jìn)行排序和比較的成本也較高，尤其在需要頻繁排序的場(chǎng)景中，性能開(kāi)銷(xiāo)更大。

• 閱讀性差：UUID是隨機(jī)生成的長(zhǎng)字符串，可讀性差，不易辨識(shí)和調(diào)試，增加了手動(dòng)操作或日志分析的難度。

解決方案

了解了兩種方案的優(yōu)缺點(diǎn)，接下來(lái)就是要取舍了，如何平衡各方？

1. 研發(fā)已經(jīng)開(kāi)始擼代碼了，時(shí)間緊任務(wù)重，本能上不愿意在這上面耗費(fèi)時(shí)間重新修改。

2. 基于安全性的原因

3. 全局唯一的需求

最后決定采用 UUID v7

UUIDv7特點(diǎn):

• 基于時(shí)間排序：

• 
  

  UUIDv7在設(shè)計(jì)上是時(shí)間順序遞增的，前42位編碼了時(shí)間戳（以毫秒為單位）。在大多數(shù)場(chǎng)景下接近順序增長(zhǎng)，從而減少隨機(jī)性帶來(lái)的插入性能開(kāi)銷(xiāo)。

• 支持高并發(fā)環(huán)境：

• 
  

  除了時(shí)間戳部分，UUIDv7還包含了一定的隨機(jī)位和節(jié)點(diǎn)ID位，以保證在同一毫秒內(nèi)生成的UUID不重復(fù)。且無(wú)需中心化的ID生成服務(wù)。

• 較好的查詢(xún)和存儲(chǔ)性能：

• 
  

  因?yàn)閁UIDv7有時(shí)間順序特性，B+樹(shù)結(jié)構(gòu)的索引可以更高效地存儲(chǔ)和查找UUIDv7，減少了數(shù)據(jù)頁(yè)分裂的情況，提高了插入和范圍查詢(xún)性能。

• 長(zhǎng)度和格式兼容：

• UUIDv7仍然保持UUID 128位長(zhǎng)度和標(biāo)準(zhǔn)格式（8-4-4-4-12），這使得它可以直接替換掉傳統(tǒng)的UUID版本而無(wú)需調(diào)整存儲(chǔ)字段格式。

以目前公司新項(xiàng)目為例，之前采用java的hutool工具生成uuid,同樣支持uuidv7。只需要更換一個(gè)調(diào)用方法即可，代碼修改量極小。

總結(jié)

特性	自增ID	UUIDv4	UUIDv7
全局唯一性	無(wú)法保證	全局唯一	全局唯一
存儲(chǔ)空間	較?。?-8字節(jié)）	較大（16字節(jié)）	較大（16字節(jié)）
插入性能	高	較低（無(wú)序插入導(dǎo)致頁(yè)分裂）	較高（接近順序插入）
排序支持	支持順序插入    查詢(xún)高效	不支持，無(wú)序	支持，按時(shí)間順序
可讀性	較高	較低	較低
信息泄露	可能泄露插入順序	隱藏插入順序	基于時(shí)間順序 部分暴露插入順序
適用場(chǎng)景	單庫(kù)系統(tǒng) 需要順序性	分布式系統(tǒng)   只需唯一性	分布式系統(tǒng)需要順序性和高插入性能