當在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並沒有導致任何鑄造問題。
就我所能估計的那樣,對於我所考慮的主要表格之一,效果會是88-> 70。 – 2008-11-19 20:26:48
可能不會太重要然後...不知道哪個數據庫使用,但在SQL Server上,IO頁面是8K,所以對於表掃描/尋求你將會從93到117每頁記錄.. 。 這些指數呢?這些int列是否在你的索引中?它可能在那裏有一個生物效應。 – 2008-11-19 20:34:06