为SQLServer查找表使用tinyint而不是int值得麻烦吗？

吃乐无穷

在SqlServer
2005中设计查找表（枚举）时，如果您知道条目数永远不会变得很高，是否应该使用tinyint而不是int？我最关心的是性能，尤其是索引的效率。
: E7 h# Q' L( t/ D% U假设您有以下代表性表格：
6 i8 n% b+ x' E3 c: J2 F" ^( u  v' x6 iPerson
. t% g8 v* `7 e$ x------
3 b7 w+ _. t+ D2 cPersonId int  (PK)
PersonTypeId tinyint  (FK to PersonTypes)
和
PersonTypes
-----------
2 r$ U; N+ c, j! ePersonTypeId tinyint
; a# m5 m8 e5 X4 v  D6 zPersonTypeName varchar(50)
. g" Q7 H: }4 w5 `显而易见的因素是数据大小和编码麻烦。当我们在人员表中获得1亿行时，我们使用tinyint而不是int来存储3亿个字节，再加上索引占用的空间。不是大量的数据，但如果将设计决策应用于数十个大表，则非常重要。当然，编码方面的麻烦来自ASP.NET
C＃/ VB代码中的所有转换问题。
如果我们撇开这两个问题，还有什么要考虑的？索引页的减少会减少查询的效率吗？还是发生某种填充会否定利益的填充？还有其他陷阱吗？
我一直只是个人使用ints，但我正在考虑tinyint即将在一些大桌子上进行重新设计/迁移工作，因此，我很乐意寻求一些建议。
' O- D' D8 o; F3 ^[编辑]
在对此进行了试验之后，我预料到的编码麻烦是没有问题的。从int更改为tinyint根本不会导致任何转换问题。
/ [6 ]- O7 X4 E/ O( A( h. w2 P               
4 ], F" A  L4 J0 [& h# ?: _. ]解决方案:
               

4 q# S! A2 i! C& b7 h9 p- Y5 ^
                表（或索引节点条目）越窄，单个IO页上可容纳的记录（或索引节点）越多，任何查询所需的物理（和逻辑）读取IO操作越少。同样，在单个页面上的索引节点越多，从根到叶的索引中索引的级别可能越少，如果通过使表变窄，则通过了可以使索引小一级的阈值，这对性能有很大的影响。
* A9 i5 j7 V5 ~8 L. o如果通过切换到TinyInt将表从200字节宽更改为197字节宽，这可能不会有任何区别…但是，如果将表从20字节更改为14，（例如，其中有2个int），那可能是戏剧性的…