在 SqlServer 2005 中设计查找表（枚举）时，如果您知道条目数永远不会变得很高，是否应该使用tinyint 而不是 int？我最关心的是性能，尤其是索引的效率。
假设您有这些代表性表格：
Person
------
PersonId int (PK)
PersonTypeId tinyint (FK to PersonTypes)
and
PersonTypes
-----------
PersonTypeId tinyint
PersonTypeName varchar(50)
明显的因素是数据大小和编码麻烦。当 person 表中的行数达到 1 亿行时，与 int 相比，使用tinyint 存储的字节数减少了 3 亿字节，再加上索引占用的空间。数据量不是很大，但如果将设计决策应用于数十个大表，则意义重大。当然，编码的麻烦来自 ASP.NET C#/VB 代码中的所有这些转换问题。
如果我们抛开这两个问题，还有什么会起作用呢？由于索引页大小的减小，查询是否会更加高效？或者是否存在某种填充只会抵消其好处？还有其他问题吗？
我个人一直只使用整数，但我正在考虑在一些巨大的表上进行即将进行的重新设计/迁移工作，所以我很想得到一些建议。
[Edit]
经过尝试后，我预期的编码麻烦被证明不是问题。从 int 更改为tinyint 根本没有导致任何转换问题。
表（或索引节点条目）越窄，单个 IO 页上可以容纳的记录（或索引节点）就越多，任何查询所需的物理（和逻辑）读取 IO 操作就越少。此外，单个页面上的索引节点越多，索引中从根到叶级别的级别就越少，如果通过使表变窄，您就通过了索引可以小一级的阈值，这可以对性能产生巨大的影响。
如果通过切换到 TinyInt 将表从 200 字节宽更改为 197 字节宽，则可能不会有任何区别...但是如果您将其从 20 字节更改为 14（假设其中有 2 个整数），那么事情可能会很戏剧化……
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
