我們有一個SQL Server 2005數據庫，我們想要提高批量刪除/插入/選擇的性能，我注意到它使用主鍵爲decimal(18,0)。我知道這會給我們帶來比bigint更多的價值，但我希望這可能是一場快速的勝利，並且應該通過我的計算持續數百萬年的增長。用於主鍵的SQL Server BIGINT或DECIMAL（18,0）
我在.NET看到docs小數取16個字節，而不是由8多頭需要的，但是在SQL Server中，它看起來像biginttake 8 bytes但decimal(18,0)只需5 bytes - 如也select DATALENGTH(max(id)) from table看到。它是否正確？
是否有其他原因bigint可能會更慢，或者我應該堅持decimal(18,0)？
DATALENGTH計數字節之前鑄造爲varchar。所以你的最大值是< 100000。
這9個字節可以證明。 sys.columns具有MAX_LENGTH柱（十進制是固定的長度，從而它始終是9個字節，則要求以其他方式之前）
CREATE TABLE dbo.foo (bar decimal(18,0))
GO
SELECT * FROM sys.columns WHERE object_id = OBJECT_ID('foo')
GO
DROP TABLE dbo.foo
GO
對於傳統的原因，decimal(18, 0)經常用作「64位整數」的替代物加入的bigint之前與SQL Server 2000
decimal(18, 0)和bigint大致在範圍是相同的：小數是一個字節以上在9個字節每文檔
作爲最重要的是，普通的整數將分數（也許不可衡量）更快然後十進制。這樣說，如果預計明年或5年有超過40億行，那麼表現應該很重要。如果不是，那麼只需使用int
bigint適合64位機器上的單個寄存器，9位小數不包含。如果我們正在談論一個遍佈整個地方的主鍵，我預計這會非常昂貴。 –
你得到該範圍內的BIGINT：
-2^63 to 2^63-1
also known as roughly:
-9.2 x 10^18 to 9.2 x 10^18
你得到該範圍內的十進制（18,0）：
-10^18 to 10^18
十進制：存儲字節每精密
Precision Storage Bytes
1-9: 5
10-19: 9
20-28: 13
29-38: 17
整數類型和存儲字節
integer type Storage Bytes
bigint 8
int 4
smallint 2
tinyint 1
思考
張貼在你的問題中的兩個例子實際上產生幾乎唯一值的數量相同。
另外，無論您的選擇如何，您都不會看到顯着的性能變化，但如果您在程序員期待整數時開始使用小數點，您將看到團隊中其他程序員的效率變化。這是一個小問題。
要解決您的特定問題，如果您想要更大的範圍，請使用十進制（38,0）。這給你：
-10^38 to 10^38
如果你關心速度，使用最小的精度將會延長軟件的使用壽命。
如果你不是在納秒測量時間，然後選擇最適合你的程序員的思維和選擇一個非常長的數字的願望的選項。
參考
在你的情況下，十進制（18,0）需要9個字節而不是5 –
DATALENGTH函數說5？ –