對於SqlServer查找表，使用tinyint而不是int值得麻煩嗎？

當在SqlServer 2005中設計查找表（枚舉）時，如果知道條目數永遠不會很高，應該使用tinyint而不是int嗎？我最關心的是績效，特別是指數的效率。對於SqlServer查找表，使用tinyint而不是int值得麻煩嗎？

比方說你有這些代表表：

Person 
------ 
PersonId int (PK) 
PersonTypeId tinyint (FK to PersonTypes)

和

PersonTypes 
----------- 
PersonTypeId tinyint 
PersonTypeName varchar(50)

最明顯的因素是數據的大小和編碼麻煩。當我們在人表中獲得1億行時，我們使用tinyint而不是int來存儲3億個字節，再加上索引佔用的空間。數據量不是很大，但如果將設計決策應用於數十個大型表格，這種數據就顯得非常重要。當然，編碼的麻煩來自ASP.NET C＃/ VB代碼中的所有投射問題。

如果我們拋開這兩個問題，還會發揮什麼作用？由於索引頁面的大小減小，查詢效率會更高嗎？或者是否有某種填充發生，只會否定好處？任何其他陷阱？

我一直只是用整數個人，但我考慮了一些巨大的表即將到來的重新設計/遷移工作TINYINT，所以我很想得到一些建議。

[編輯]

與此試驗後，編碼麻煩我預期的竟然是一個非問題。從int更改爲tinyint並沒有導致任何鑄造問題。

來源

2008-11-19 Eric Z Beard

較窄的表（或索引節點的條目），則更多的記錄（或索引節點）可以適合在單個IO頁上，並且較少的物理（和邏輯的）讀取IO操作所需要的任何查詢。此外，單個頁面上的索引節點越多，索引中可能存在的級別越少（從根到葉級別），並且如果通過縮小表的範圍，您就可以通過閾值（索引可以小一級）可以對穿透性產生戲劇性的影響。

如果切換到TINYINT你從200個字節更改表寬至197個字節寬，它可能不會有任何區別。但是，如果你從20個字節更改爲14，（說你有2個整數在那裏），那麼它可能是巨大的......

來源

2008-11-19 20:13:06

就我所能估計的那樣，對於我所考慮的主要表格之一，效果會是88-> 70。 – 2008-11-19 20:26:48

可能不會太重要然後...不知道哪個數據庫使用，但在SQL Server上，IO頁面是8K，所以對於表掃描/尋求你將會從93到117每頁記錄.. 。這些指數呢？這些int列是否在你的索引中？它可能在那裏有一個生物效應。 – 2008-11-19 20:34:06

我懷疑使用SMALLINT不是int的將會有多大的性能優勢，除了在罕見的極端情況。您可以輕鬆構建測試應用程序，創建一些測試表並執行一百萬次插入/更新/選擇並比較性能。

來源

2008-11-19 20:11:09 Craig

內存101：更小的東西是指在一次持有更多的RAM，從而減少硬盤讀取。如果數據庫足夠大並且正在運行某些查詢，這可能是一個非常嚴重的因素。但它可能不會有很大的變化。

來源

2008-11-19 20:13:34 Brian

還有維護索引/磁盤備份/磁帶備份這也將佔用空間的因素，但我想說的最重要的是IO和內存的性能。

來源

2008-11-19 20:22:20 Sam

任何其他陷阱？

我不知道這是什麼樣的「疑難雜症」你的意思，但我已經在那裏使用日期時間，而不是SMALLDATETIME了不正確的操作行爲碰上的情況下，因爲較低的精度SMALLDATETIME沒」與其他情況下「相同」的兩個日期的高精度日期時間相當。

這裏沒有發生這種情況的機會，因爲對於相同的數字整數值，tinyint/smallint/int/bigint將全部相同。所以你在這方面顯然是安全的，並不是它完全回答你的問題。

來源

2008-11-19 20:50:46

對於SqlServer查找表，使用tinyint而不是int值得麻煩嗎？

回答

相關問題