狠狠色丁香婷婷综合尤物/久久精品综合一区二区三区/中国有色金属学报/国产日韩欧美在线观看 - 国产一区二区三区四区五区tv

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

頭大，想要研發改成自增id，結果研發來一句，自增id不利于數據安全。

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

但是，此題還得解。

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

核心要點

1. 為什么用自增ID

2. 自增ID的優缺點

3. UUID的優缺點

4. 解決方案

5. 總結

為什么用自增ID

為什么DBA總是強調要用自增id做主鍵？

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

MySQL數據如何存儲：

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表的數據是按照主鍵的順序進行存儲的。

其次，

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

有序主鍵和無序主鍵的區別：

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

存儲性能：

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

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

查詢性能：

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

2. 無序主鍵（例如UUID）

存儲性能：

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

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

查詢性能：

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

自增ID的優缺點

優點：

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

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

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

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

缺點：

• 存在業務數據泄露風險：連續的ID可能會讓人推測出插入的總數量或增長規律，可能導致數據泄露風險。

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

• 無法保證全局唯一：自增ID通常是數據庫實例內部唯一，難以在分布式環境下保證全球唯一性。

UUID的優缺點

優點：

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

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

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

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

缺點：

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

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

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

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

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

解決方案

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

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

2. 基于安全性的原因

3. 全局唯一的需求

最后決定采用 UUID v7

UUIDv7特點:

• 基于時間排序：

• 
  

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

• 支持高并發環境：

• 
  

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

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

• 
  

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

• 長度和格式兼容：

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

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

總結

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