是SQL Server中必需的主鍵嗎？

Question

這可能是一個非常天真和愚蠢的問題，但無論如何我都會問它

我有一個包含多個字段的表，其中沒有一個是唯一的，還有一個主鍵，顯然是。

此表通過非唯一字段定期訪問，但沒有用戶SP或進程通過主鍵訪問數據。 那么主鍵是必要的嗎？ 它是在幕后使用的嗎？ 刪除它會影響性能的正面還是負面？

Answer 1

必要？ 沒有在幕后使用？ 好吧，它保存到磁盤並保存在行緩存等中。刪除會略微提高性能（使用精度為毫秒精度的手表）。

但是......下次有人需要創建對此表的引用時，他們會詛咒你。 如果他們勇敢，他們將添加PK（並等待DB創建列的時間很長）。 如果他們不勇敢或愚蠢，他們將開始使用業務鍵（即數據列）創建引用，這將導致維護噩夢。

結論：由於PK的成本（即使它沒有使用ATM）是如此之小，所以就這樣吧。

Answer 2

你有外國鑰匙，你有沒有加入PK？

如果答案是否定的，並且您的應用程序永遠不會通過其PK從表中檢索項目，並且沒有查詢在where子句中使用它，那么您只需添加IDENTITY列以獲得PK，然后：

• PK本身沒有增加任何價值，但也沒有任何損害
• 事實上PK很可能也是聚集索引.. 這取決於 。

如果你有NC索引，那么你有一個狹窄的人工聚類密鑰（IDENTITY PK）的事實有助於保持這些索引變窄（CDX密鑰在每個NC葉子槽中再現）。 因此，如果您有重要的NC索引，即使從未使用PK，也會有所幫助。

另一方面，如果您有一個流行的訪問模式，某個超過所有其他查詢的查詢是頻率和重要性，或者是關鍵時間代碼路徑的一部分（例如，在您網站上每次訪問頁面時運行查詢）或者每秒和app等）然后該查詢是指示聚簇鍵順序的良好候選者。

最后，如果表很少被查詢但經常被寫入，那么它可能是HEAP的良好候選者（根本沒有集群密鑰），因為堆在插入方面要好得多。 請參閱比較使用群集索引與堆組織的表 。

Answer 3

主鍵是幕后clustered index （默認情況下除非生成為非聚簇索引）並保存表的所有數據。 如果PK是標識列，則插入將按順序發生，並且不會發生頁面拆分。

但是如果你根本不訪問id列，那么你可能想在其他列上添加一些索引。 此外，當您有PK時，您可以設置FK關系

Answer 4

在邏輯模型中，表必須至少有一個鍵。 沒有理由任意指定其中一個鍵是'主鍵'; 所有鍵都相等。 盡管“主鍵”的概念可以追溯到特德·科德的早期作品，但早期的錯誤在關系理論中早已得到糾正。

可悲的是， PRIMARY KEY發現它已經進入SQL，我們不得不忍受它。 SQL表可以有重復的行，如果您認為SELECT查詢的結果集也是一個表，那么SQL表也可以有重復的行。 關系理論家不喜歡SQL。 但是，僅僅因為SQL允許你做各種古怪的非關系事物，這並不意味着你必須真正做到這一點。 確保每個SQL表至少有一個密鑰是一種好的做法。

在SQL中， PRIMARY KEY使用PRIMARY KEY會產生影響，例如NOT NULL ， UNIQUE ，表的外鍵默認引用。 在SQL Server中， PRIMARY KEY使用PRIMARY KEY會產生影響，例如表的聚簇索引。 但是，在所有這些情況下，可以使用特定語法使隱式行為顯式化。

您可以組合使用UNIQUE （約束而不是索引）和NOT NULL來強制SQL中的鍵。 因此，不，SQL Server中不需要主鍵（甚至PRIMARY KEY ）。

Answer 5

我永遠不會有沒有主鍵的表。 假設您需要刪除重復項 - 您將如何識別要刪除哪個副本以及要保留哪個副本？

Answer 6

定義時的主鍵有助於提高數據庫內的索引和關系性能。

我總是傾向於在我的所有表中將主鍵定義為自動遞增整數，無論​​我是否訪問它，這是因為當您開始擴展應用程序時，您可能會發現實際上需要它，並且它讓生活變得更簡單。

Answer 7

PK不是必需的。

但是您應該考慮在用於查詢的列上放置一個非唯一索引（即出現在WHERE子句中）。 這將大大提高查找性能。

Answer 8

主鍵實際上是域模型的屬性，它唯一地標識域對象的實例。

在單個增加的列（例如標識列）上具有聚簇索引將意味着不會發生頁面拆分，但是插入將使索引隨時間失衡，因此重建索引需要定期完成（或者當碎片達到某個閾值時） 。

我必須有一個很好的理由來創建一個沒有主鍵的表。

Answer 9

如果您通過非關鍵字段訪問它們，性能可能不會改變。 但是，保留PK以用於將來對這些表的增強或接口可能會很好。 您的應用程序僅使用此表嗎？

Answer 10

正如SQLMenace所說，聚簇索引是表的物理布局的重要列。 另外，擁有聚簇索引，特別是像瘦整數pk那樣精心選擇的聚簇索引，實際上會提高插入性能。