爲未來安全的數據密集型數據庫提供更好的PK

Question

我們真的在爲我們新的數據密集型項目設計主鍵時遇到技術問題。

請說明我們的數據密集型數據庫更適合哪種PK設計。

1. 該數據庫是數據密集型和持久性的。
2. Atleast 3000用戶每秒訪問它。

請問我們的數據庫哪種類型的PK更好，表格在未來不太可能改變。

1.INT/BIGINT自動增量列爲PK

2.複合鍵。

3.Unique varchar PK。

Answer 1

我會選擇1，使用BIGINT自動增量列作爲PK。原因很簡單，每次寫入都會寫入當前頁面的末尾，這意味着插入新行非常快。如果您使用組合鍵，那麼您需要一個訂單，除非您按照組合鍵的順序插入，否則您需要拆分頁面以插入，例如，設想這樣的表：

A | B | C 
---+---+--- 
1 | 1 | 4 
1 | 4 | 5 
5 | 1 | 2 

當主鍵是在複合鍵（A，B，C），假設我要插入（2，2，2），這將需要插入如下：

A | B | C 
---+---+--- 
1 | 1 | 4 
1 | 4 | 5 
2 | 2 | 2 <---- 
5 | 1 | 2 

這樣聚簇鍵維護其順序。如果您已經插入的頁面已滿，那麼MySQL將需要拆分頁面，將一些數據移動到新頁面，以便爲新數據騰出空間。這些頁面拆分非常昂貴，因此除非您知道要插入順序數據，否則使用自動增量列作爲集羣鍵意味着除非您亂搞增量，否則不應該拆分頁面。

你仍然可以爲保持完整性的主鍵添加一個唯一的索引，你仍然會對索引上的拆分有同樣的問題，但由於索引會比聚簇索引更窄，拆分因爲更多的數據可以放在頁面上，所以不會那麼頻繁。

或多或少的相同的參數適用於唯一的varchar列，除非您有某種確保varchar是連續的過程，但生成順序varchar比自動增量列更昂貴，並且我不能立即看到優點。

Answer 2

這並不容易回答。

首先，使用複合鍵作爲主鍵是直接的方法。當數據庫結構發生變化時，ID會派上用場。

假設您在不同國家/地區銷售不同尺寸的產品。主鍵是粗體。

• 產品（product_no，名稱，supplier_no，...）
• product_size（product_no，大小，EAN措施，...）
• product_country（product_no，country_isocode，translated_name，...）
• product_size_country（product_no，大小，country_isocode，增值稅，...）

這是很容易WITE數據，因爲你正在處理自然鍵，這是用戶使用的。 dbms保證了數據的一致性。

現在同樣的技術標識：

• 產品（PRODUCT_ID，product_no，名稱，supplier_no，...）
• product_size（product_size_id，大小，PRODUCT_ID，EAN措施， ...）
• product_country（product_country_id，PRODUCT_ID，COUNTRY_ID，translated_name，...）
• product_siz e_country（product_size_country_id，product_size_id，COUNTRY_ID，增值稅，...）

要得到的ID是現在需要一個額外的步驟，插入數據時。你仍然必須確保product_no是唯一的。因此，product_id上的唯一約束不會替代product_no上的該約束，而是添加到它。 product_size，product_country和product_size_country相同。而且，product_size_country現在可以鏈接到不同產品的product_country和product_size_country。 dbms不能保證數據的一致性。

但是，必須對數據庫結構進行更改時，自然鍵有其弱點。假設在數據庫中引入了一家新公司，並且每個公司的產品號碼都是唯一的。使用基於ID的數據庫，您只需將公司ID添加到產品表中即可完成。在基於自然鍵的數據庫中，您必須將公司添加到所有主鍵。更多的工作。 （但是，多長時間一次必須對數據庫進行這樣的更改，在很多數據庫中從不）

還有什麼需要考慮的？當數據庫變大時，可能需要對錶進行分區。使用自然鍵，您可以通過所述公司劃分您的桌子，假設您通常希望從一家公司或另一家公司選擇數據。使用ID，您將通過分區來增強訪問權限？

那麼，這兩個概念肯定有優點和缺點。至於你的第三個選項來創建一個唯一的varchar，我看到使用整數ID沒有任何好處。