为SqlServer查找表使用tinyint而不是int是否值得？

在SqlServer 2005中设计查找表(枚举)时,如果你知道条目的数量永远不会很高,你应该使用tinyint而不是int吗？我最关心的是性能,特别是索引的效率.

假设您有这些代表性表格:

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

和

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

显而易见的因素是数据大小和编码麻烦.当我们在person表中获得1亿行时,我们使用tinyint而不是int存储3亿个字节,加上索引占用的空间.不是大量的数据,但如果将设计决策应用于数十个大表,则意义重大.当然,编码麻烦来自ASP.NET C#/ VB代码中的所有那些转换问题.

如果我们搁置这两个问题,还有什么可以发挥作用？由于索引页面的大小减小,查询会更有效吗？或者是否存在某种填充,只会否定其好处？还有其他陷阱吗？

我一直只是个人使用,但我正在考虑在一些巨大的桌子上进行重新设计/迁移工作的tinyint,所以我很想得到一些建议.

[编辑]

在尝试了这个之后,我预期的编码麻烦结果证明是无问题的.从int更改为tinyint并没有导致任何铸造问题.

表(或索引节点条目)越窄,单个IO页面上的记录(或索引节点)就越多,并且任何查询都需要更少的物理(和逻辑)读取IO操作.此外,单个页面上的索引节点越多,索引中的级别就越少,从根级别到叶级别,如果通过使表格更窄,则通过阈值,其中索引可以小一级,可以对穿孔产生戏剧性的影响.

如果通过切换到TinyInt,您将表从200字节宽更改为197字节宽,它可能不会有任何区别......但如果您将其从20字节更改为14,(比如说你有2个整数),然后它可能是戏剧性的......