日韩欧美人妻无码精品白浆,夜夜嗨AV免费入口,国产欧美官网在线看,高校回应聋哑女生因长相完美被质疑

最近，公司剛剛開了一個新項目，研發(fā)丟過來的建表語句，一看全都是uuid做主鍵。。。

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

對于一個對數(shù)據(jù)安全要求高的公司來說，這一句秒殺了。

但是，此題還得解。

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

核心要點

1. 為什么用自增ID

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

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

4. 解決方案

5. 總結

為什么用自增ID

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

這也是研發(fā)同學一直以來的疑問，一般DBA會說基于性能考慮。具體為什么，可能也沒詳細解釋過。今天，簡單明了地解釋一下。

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

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.

首先，

官方手冊中關于聚集索引有詳細的說明

InnoDB表存儲基于主鍵列的值進行組織

這類表又稱之為索引組織表

總結一句話就是：MySQL的innodb表的數(shù)據(jù)是按照主鍵的順序進行存儲的。

其次，

MySQL數(shù)據(jù)庫在磁盤上按數(shù)據(jù)頁進行存儲的，每個數(shù)據(jù)頁的默認大小為16k

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

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

存儲性能：

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

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

查詢性能：

• 順序插入的數(shù)據(jù)在物理上是連續(xù)存儲的，因此基于主鍵的范圍查詢效率較高，減少了磁盤隨機讀寫的次數(shù)。尤其是大范圍查詢時，數(shù)據(jù)連續(xù)分布在少數(shù)數(shù)據(jù)頁中，可以減少IO操作。

2. 無序主鍵（例如UUID）

存儲性能：

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

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

查詢性能：

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

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

優(yōu)點：

• 唯一性：每個記錄的自增ID是唯一的，能夠滿足主鍵的唯一性要求。

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

• 索引構建和維護成本低：因為自增ID按順序增長，InnoDB在插入數(shù)據(jù)時無需頻繁調(diào)整數(shù)據(jù)位置，索引維護成本較低，性能較高。

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

缺點：

• 存在業(yè)務數(shù)據(jù)泄露風險：連續(xù)的ID可能會讓人推測出插入的總數(shù)量或增長規(guī)律，可能導致數(shù)據(jù)泄露風險。

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

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

UUID的優(yōu)缺點

優(yōu)點：

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

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

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

• 避免信息泄露：UUID的隨機性避免了可能會暴露插入的順序或數(shù)量這一風險，增強了數(shù)據(jù)的安全性。

缺點：

• 插入性能低：UUID是無序的隨機字符串，在B+樹等結構中不能按順序插入，導致頻繁的頁分裂，增加了數(shù)據(jù)庫索引的維護開銷，影響插入性能。

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

• 查詢性能差：因為UUID是無序的，基于UUID的范圍查詢性能低。UUID在數(shù)據(jù)頁中分布分散，導致更多的磁盤隨機讀取，而不是連續(xù)讀取，增加了IO負擔。

• 排序和對比成本高：UUID長度較長，進行排序和比較的成本也較高，尤其在需要頻繁排序的場景中，性能開銷更大。

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

解決方案

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

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

2. 基于安全性的原因

3. 全局唯一的需求

最后決定采用 UUID v7

UUIDv7特點:

• 基于時間排序：

• 
  

  UUIDv7在設計上是時間順序遞增的，前42位編碼了時間戳（以毫秒為單位）。在大多數(shù)場景下接近順序增長，從而減少隨機性帶來的插入性能開銷。

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

• 
  

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

• 較好的查詢和存儲性能：

• 
  

  因為UUIDv7有時間順序特性，B+樹結構的索引可以更高效地存儲和查找UUIDv7，減少了數(shù)據(jù)頁分裂的情況，提高了插入和范圍查詢性能。

• 長度和格式兼容：

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

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

總結

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