对于SqlServer查找表,使用tinyint而不是int是值得的吗?

在SqlServer 2005中设计一个查找表(枚举)时,如果您知道条目数将不会变得非常高,那么应该使用tinyint而不是int吗?我最关心的是性能,特别是索引的效率。

假设你有这些代表表:

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

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

明显的因素是数据大小和编码麻烦。当我们在个人表中达到1亿行时,我们正在使用tinyint存储3亿个字节,而不是int,加上索引占用的空间。数据量不大,但如果设计决定适用于数十个大桌子,则重要。编码麻烦当然来自ASP.NET C#/ VB代码中的所有这些问题。

如果我们抛开这两个问题,还有什么呢?由于索引页面的尺寸减少,查询会更有效吗?还是有一些填补,发生只会否定好处?其他任何问题?

我一直只是使用ints,但我正在考虑tinyint,即将在一些巨大的桌子上进行重新设计/迁移工作,所以我很乐意得到一些建议。

[编辑]

经过实验,我预期的编码麻烦证明是一个非问题。从int到tinyint的改变并没有导致任何铸造问题。

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

如果通过切换到TinyInt,您将表从200字节宽改为197字节宽,这可能不会有任何区别…但是如果将它从20个字节更改为14,(说你有2个int)那么它可能是戏剧性的

相关文章
相关标签/搜索