是否應該將主鍵始終添加到innodb表中？

我有一些innoDbs只有2個int列，它們是其他表的主鍵的外鍵。是否應該將主鍵始終添加到innodb表中？

E.g一個表是user_items，它有2列，用戶id，的itemId，外國鍵的用戶和項目表，如果更新或刪除設置爲級聯。

我應該第3列添加到這些表，並使它成爲一個主鍵，或者是更好它是現在，在性能方面或任何其他好處的方式？

在這種情況下，您應該堅持使用自然鍵作爲主鍵。當你有一個複雜的自然鍵時，使用代理鍵作爲你的主鍵是有用的，但在這種情況下，我認爲這裏沒有太多的東西需要獲得。 –

添加第三個ID欄只是用於添加ID列起見沒有意義的。實際上，當您插入或刪除行時，它只會增加處理開銷（索引維護）。

主鍵不一定是「一個ID列」。

如果您只允許用戶和項目之間的單個關聯（用戶不能分配兩次相同的項目），那麼將(userid, itemid)定義爲表格的主鍵確實有意義。

如果您允許同一對出現不止一次那麼你當然不需要那麼約束。

2012-06-24 09:59:28

定義（userId，itemId）作爲主鍵有什麼用處？ –

@ClickUpvote：正如我所說：如果有一個要求，一個用戶只能被分配一次的項目（我不知道 - 只有你知道），你想確保這個要求不被違反定義該組合主鍵（=唯一約束） –

@ClickUpvote如果需要同一用戶和項目之間的多個關聯，則無論如何都需要一個用於區分它們的字段，並且只需將_it_添加到PK。無論哪種情況，您都不能輕鬆離開桌子。即使你嘗試了，InnoDB也會爲你創建一個隱藏的PK，因爲它必須有_some_ PK來對數據進行聚類。 –

一般來說，如果它沒有增加真正的複雜性，你正在編寫的代碼和表格預計包含100,000-500,000行或更少，我建議添加主鍵。我有時還建議添加created_at和updated_at列。

是的，他們需要更多的存儲 - 但它是最小的。還有一個問題，即主鍵索引將不得不維護，因此如果表變大，插入和更新可能會變慢。但是除非表格很大（幾百或幾百行），否則處理速度可能沒有什麼區別。

所以，除非該表將是相當大的，在空間和處理速度的影響是微不足道的 - 所以你就需要多少精力來維護它，它提供的潛在效用的決定。如果它只需要很少的額外代碼，那麼它提供的任何實用程序都可能使其值得。

擁有主鍵的最好理由之一是根據它們被插入的順序爲行提供自然順序。如果您想要檢索添加的最後100個（或前100個）行，那麼如果您在表上具有自動增量主鍵，則它非常簡單快捷。

添加inserted_at和updated_at列可以在基於日期範圍提取數據方面提供類似的實用程序。同樣，除非行數會非常大，否則也可能需要評估這些值。

2012-06-24 10:43:47

您已擁有天然鑰匙{userId, itemId}。除非添加另一個（代理）密鑰的特定原因，否則只需使用您現有的密鑰作爲主密鑰。

一些原因替代可能包括：

我不認爲這適用於您的情況。

此外，請注意，InnoDB tables are clustered和集羣表中的次要索引比基於堆的表中的次要索引要貴。所以理想情況下，你應該儘可能避免二級索引。

2012-06-24 10:50:25

回答