使用 VARCHAR 鍵或 INT

我正在基於yelp dataset在 MySQL 中建構一個數據倉庫。

數據集中的大多數鍵都以字元串形式給出：

user_id                 review_id               business_id
hzw-qTUVpmLAKjdkoUNh8A  Awq_6cyNjK1-qPZAwnXjjQ  7p6tHUA1Pknh0DVWqz86lA
mldKxVI59o3LhK3ITG6mnA  96YkAuJzlT54qZZWNebFUg  7p6tHUA1Pknh0DVWqz86lA
SaedHW9i7k4lHR8tgwtMgQ  OfZRG7RgKA118zDtj6yo-g  7p6tHUA1Pknh0DVWqz86lA

我應該將它們轉移到自行生成的密鑰（自動增量整數）還是保持原樣（VARCHAR(22)）。

主鍵/外鍵數據類型選擇有哪些注意事項？

謝謝

沒有更多資訊，您的問題沒有明確的答案。但是，您的選擇應該基本上基於：

1. 易於數據載入：如果您保留密鑰原樣，您將省去很多創建等效INTEGERid 的麻煩（您需要在每對之間建立一個等效表；並在使用ETL導入數據時使用此轉換錶過程）。如果所有鍵的長度都是 22 個字元，那麼您最好使用char(22)而不是varchar(22) 1。（針對 AUTO_INCREMENT）
2. Size：如果您的數據集非常大，進行轉換將為您在表行和索引中節省大量空間。如果有很多包含多個varchar(22)列和額外列的索引，則可以達到索引大小2的限制。索引（和表）越小，系統查詢的性能就越高。（臨 AUTO_INCREMENT）
3. 新鍵：如果您想向數據集添加更多行，擁有一個AUTO_INCREMENT鍵比擁有生成varchar(22)唯一 ID 的機制更容易。（臨 AUTO_INCREMENT）

根據您的特定需求，權衡利弊，然後選擇。

鑑於Yelp Dataset的性質，我可能會選擇INT，只是為了提高大小效率。您需要翻譯business_id、review_id和。如果您必須已經從 JSON 轉換為 CSV，並將數組轉換為規範化的子表，然後才能上傳不同的集合，那麼多做一個步驟應該不會那麼困難。user_id``photo_id

---

備註：

1. >

如果您的內容是固定大小的，您將使用 CHAR 獲得更好的性能。

來自：VARCHAR 和 CHAR 有什麼區別？ 2. >

頁面大小為 8KB 時最大索引鍵長度為 1536 字節，頁面大小為 4KB 時最大索引鍵長度為 768 字節。

從14.8.1.7 InnoDB 表的限制

---

旁注：考慮使用PostgreSQL和MADLib。我認為這種組合可能會為您提供一些有用的工具來應對此類挑戰。

引用自：https://dba.stackexchange.com/questions/177767