是否有任何理由避免使用bigint代替主鍵？

我正在設計一個數據庫，並且我有許多表可能超過了標準32位int的最大大小。然而，在這種情況發生之前可能會有好幾年的時間，並且不能保證它甚至會發生。是否有任何理由避免使用bigint代替主鍵？

但是，考慮到有可能發生這種情況，我應該繼續並選擇bigint作爲主鍵嗎？現在做這件事和稍後改變它的含義是什麼？以後甚至有可能將一個int主鍵轉換爲bigint，如果是的話，它有多難度和可行性？

2015-08-20 Jason Clement

對於最後一個問題[在int服務器中將int主鍵轉換爲bigint]（http://stackoverflow.com/questions/5461205/converting-int-primary-key-to-bigint-in-sql-server）。如果您的表格如此之大，請考慮對舊數據進行分區或歸檔。 – lad2025

假設你使用的是無符號的32位整數，那麼使用無符號的64位整數將會「浪費」每個記錄2個字節，總計8GB，直到你超過32位邊界。如果你的服務器無法處理8gig的「浪費」空間，那麼就使用32bit。 –

SQL Server支持[無符號整數]（https://connect.microsoft.com/SQLServer/feedback/details/515502/unsigned-integer-data-type）？ – DMason

去BIG會花費你的存儲和性能 - 尤其是如果它意味着你的外鍵引用也必須是BIGINT。

提前看「年」並不一定是謹慎的事情。預計大部分（不是全部）IT項目將在3年內收回成本。如果您的數據庫在這段時間內增長過多，那麼您很可能不得不面對多年來進行的大量更改和升級，如果需要，在沒有必要時將INT更改爲BIGINT。那麼也許你的業務和數據庫世界總的來說已經開始了，它不會再成爲一個問題了。 YAGNI規則。

來源

2015-08-20 20:58:46 sqlvogel

真的沒有理由避免它本身。它確實需要更多的存儲空間。如果這是主鍵列，除非首先刪除主鍵，否則不能更改數據類型。假設你命名你的主鍵約束，這很簡單。你不必創建一個新的專欄，並像lad2025的評論那樣做所有的事情。

create table IntTest 
(
    MyID int identity 
    , SomveValue uniqueidentifier 
    , constraint IntTest_PK primary key clustered (MyID) 
) 

insert IntTest 
select NEWID() 
from sys.all_columns 

alter table IntTest drop constraint IntTest_PK 

alter table IntTest alter column MyID BigInt 

alter table IntTest add constraint IntTest_PK primary key clustered (MyID)

來源

2015-08-20 20:37:30

我們剛剛發現我們的bigint PK正在爲我們的查詢添加6秒。看起來科學已經進入並壓縮了我們使用bigint的PKs。 –

是否有任何理由避免使用bigint代替主鍵？

回答

相關問題