字符串作爲SQL數據庫中的主鍵

Question

我對數據庫和它們工作原理背後的理論不是很熟悉。從性能的角度來看，插入/更新/查詢使用主鍵的字符串比整數更慢嗎？

Answer 1

技術上是可以的，但如果一個字符串有意義的是主鍵，那麼你應該使用它。這一切都取決於你所使用的表的大小以及將成爲主鍵的字符串的長度（較長的字符串==比較難）。我不一定會爲具有數百萬行的表使用字符串，但是通過在較小的表上使用字符串可以獲得的性能下降量對於令人頭痛的問題來說可能是微不足道的，這與數據無關。

Answer 2

指數意味着大量的比較。

通常，字符串是不是整數和歸類規則可以被應用於用於比較長，所以在比較字符串通常比比較整數更加計算密集的任務。

然而，有時候，它的速度更快使用字符串作爲主鍵，而不是做一個string to numerical id表的額外加入。

Answer 3

變量太多。它取決於表的大小，索引，字符串關鍵域的性質...

一般，整數會更快。但是這種差異是否足夠大？這很難說。

此外，什麼是您選擇的字符串動機是什麼？數字自動遞增鍵通常非常容易以及更容易。它是語義嗎？方便？複製/斷開的擔憂？你的答案可能會限制你的選擇。這也讓人想起你忘記的第三個「混合」選項：Guids。

Answer 4

使用字符串作爲主鍵的另一個問題是，由於指數不斷投入順序，當創建新的密鑰，這將是該指數有秩序的中間被重新排序...如果您使用自動編號整數，新的關鍵字只是添加到索引的末尾。

Answer 5

是的，但除非您希望有數百萬行，不會使用基於字符串的鍵，因爲速度較慢通常是「不成熟的優化」。畢竟，字符串被存儲爲大數字，而數字鍵通常被存儲爲較小的數字。

但要注意的一件事情是，如果您在任意鍵上有聚簇索引並且在索引中執行大量非順序插入操作。每一行寫入都會導致索引重新寫入。如果你正在進行批量插入，這可以真正減慢過程。

Answer 6

你是什麼原因，有一個字符串作爲主鍵？

我只是將主鍵設置爲自動遞增整數字段，並在字符串字段上放置索引。

這樣，如果您在桌面上進行搜索，它們應該相對較快，並且所有連接和正常查找的速度都不會受到影響。

您還可以控制獲取索引的字符串字段的數量。換句話說，如果你認爲這足夠了，你可以說「只索引前5個字符」。或者如果你的數據可能比較相似，你可以索引整個領域。

Answer 7

只要它是唯一的，你用什麼作爲主鍵並不重要。如果您關心速度或數據庫設計，請使用int，除非您計劃複製數據，然後使用GUID。

如果這是一個訪問數據庫或一些小應用程序，那麼誰真正關心。我認爲我們大多數開發人員在前線抨擊舊int或guid的原因是因爲項目對我們有一種增長的方式，並且您希望讓自己成長。

Answer 8

字符串在連接中速度較慢，而且在現實生活中，它們很少是非常獨特的（即使它們應該是）。唯一的好處是，如果您只加入主表以獲取名稱，它們可以減少連接數。但是，字符串也經常發生變化，從而造成當公司名稱改變或結婚時必須修復所有相關記錄的問題。這可能會造成巨大的性能下降，並且如果所有應該相關的表都不相關（這種情況發生的頻率比您想象的要高），那麼您可能也會遇到數據不匹配的情況。從數據完整性角度以及從性能角度來看，在整個記錄生命週期中永遠不會改變的整數是更安全的選擇。自然鍵通常不太適合維護數據。

我也想指出，兩個世界中最好的經常是使用自動增量密鑰（或在一些特殊情況下，一個GUID）作爲PK，然後在自然鍵上添加一個唯一的索引。您可以獲得更快的聯接，您不會獲取重複的記錄，並且您不必更新一百萬條子記錄，因爲公司名稱已更改。

Answer 9

數據庫中可能存在與字符串相關的非常大的誤解。幾乎每個人都認爲數字的數據庫表示比字符串更緊湊。他們認爲在db-s中的數字表示在內存中。但事實並非如此。在大多數情況下，數字表示更接近像其他字符一樣的表示。

使用數字或字符串的速度更依賴於索引，然後是類型本身。

Answer 10

從性能的角度來看 - 與使用整數（PK）實現的性能相比，字符串（PK）會降低性能，其中PK --->主鍵。

從要求的角度來看 - 雖然這不是你問題的一部分，但我還是要提一下。當我們處理跨越不同表格的大量數據時，我們通常會查找可以爲特定表格設置的可能鍵集。這主要是因爲有許多表，並且大多數每個或某個表通過某種關係（外鍵的概念）與另一個表相關。因此，我們實際上不能總是選擇一個整數作爲主鍵，而是將3,4或5個屬性組合爲該表的主鍵。當我們將記錄與其他表相關聯時，這些鍵可以用作外鍵。這可以在需要時將記錄跨不同表格進行關聯。

因此，爲了最佳使用 - 我們總是將1個或2個整數與1或2個字符串屬性組合，但只有在需要時纔會再次使用。

Answer 11

除非您有一個簡單且完善的設計，並且符合數據描述的主題並與數據的預期用途相符，否則不要擔心性能。然後，如果性能問題出現，您可以通過調整系統來處理它們。

在這種情況下，使用字符串作爲自然主鍵幾乎總是更好，因爲您可以信任它。不要擔心，如果它是一個字符串，只要字符串相當短，比如說最多25個字符。在性能方面你不會付出很大的代價。

數據錄入人員或自動數據源是否始終爲所假定的自然鍵提供值，或者有時會忽略？輸入數據偶爾會出錯嗎？如果是這樣，那麼如何檢測和糾正錯誤？

指定查詢的程序員和交互式用戶是否可以使用自然鍵來獲得他們想要的？

如果你不能相信自然的關鍵，發明一個替代品。如果你發明了一個代理，你也可以發明一個整數。那麼你不得不擔心是否會隱瞞用戶社區的代理人。一些不隱瞞代理鍵的開發者後悔了。

Answer 12

插入到具有聚集索引的表中，其中插入發生在序列中間不會導致索引被重寫。它不會導致組成數據的頁面被重寫。如果行所在的頁面上有空間，則將其放置在該頁面中。單頁將被重新格式化以將該行放置在頁面中的正確位置。當頁面已滿時，會發生頁面拆分，頁面上的一半行將進入一頁，另一半則進入另一頁。這些頁面然後被重新鏈接到包含具有聚簇索引的表格數據的頁面的鏈接列表中。至多，你最終會寫2頁的數據庫。

Answer 13

兩個原因使用整數的PK列：

1. 我們可以設置爲自動遞增整數字段標識。

2. 當我們創建PK時，數據庫會創建一個索引（集羣或非集羣），在數據存儲在表中之前對其進行排序。通過在PK上使用標識，優化器在保存記錄之前不需要檢查排序順序。這可以提高大表的性能。

Answer 14

默認情況下ASPNetUserIds是128個字符串，性能很好。

如果密鑰HAS在表中是唯一的，它應該是密鑰。這是爲什麼;

主鍵字符串鍵=正確的數據庫關係，1個字符串鍵（主鍵）和1個字符串索引（主鍵）。

另一種選擇是一個典型的INT關鍵，但如果字符串的HAS是唯一的你還可能會需要增加，因爲不停的查詢索引，以驗證或確認其獨到之處。

因此，使用int identity key =不正確的數據庫關係，1個int鍵（主鍵），1個int索引（主鍵），可能是一個唯一的字符串索引，並且手動必須驗證相同的字符串不存在像一個SQL檢查可能）。

要使用一個int在該主鍵的字符串，獲得更好的性能，當字符串HAS必須是唯一的，它必須是一個非常奇怪的情況。我一直傾向於使用字符串鍵。作爲一個很好的經驗法則，除非你需要需要。