何时在INT上使用TINYINT？

通常，我总是使用Ints。我知道，从理论上讲，这不是最佳实践，因为您应该使用可以保证存储数据的最小数据类型。

例如，最好tinyint在知道将要存储的唯一数据是1、0或null（极少有机会将其扩展到2或3）后使用。

但是，我知道这样做的唯一原因是出于存储目的-在一行中使用1个字节而不是4个字节。

除了节省硬盘驱动器上的空间之外，仅使用tinyint（或smallint什至bigint）有什么影响int？

磁盘空间很便宜……这不是重点！

不要再考虑存储空间，而要考虑缓冲池和存储带宽。在最末端，CPU缓存和内存总线带宽。链接的文章是该系列文章的一部分，着重介绍了集群键选择不佳的问题（INT vs GUID vs Sequential GUID），但它着重强调了字节可能造成的差异。

最重要的信息是设计问题。直到您到达VLDB区域，差异才会显示在具有适当规格的服务器上的单个数据库中，但是如果您可以节省一些字节，那为什么不这样做。

我想起了先前问题中描述的环境。每个SQL实例400多个数据库，大小从50mb-50GB不等。在该环境中，每个记录，每个表，每个数据库清理几个字节可能会产生很大的不同。

除了其他答案...

行和索引条目存储在8k页中。因此，每行3个字节的一百万行不是磁盘上的3 MB：它会影响每页的行数（“页面密度”）。

这同样适用于nvarchar到varchar，smalldatetime到datetime，int到tinyint等

编辑，2013年6月

http://sqlblog.com/blogs/joe_chang/archive/2013/06/16/load-test-manifesto.aspx

这篇文章指出

重要标准是基数和页与行的比率。

因此，数据类型的选择很重要

不仅要考虑表存储。如果使用int列是复合键的一部分的索引，则自然会希望索引页尽可能完整，这是由于索引项越小越好。

我绝对希望发现使用较小的数据类型来检查BTREE页面中的索引条目会更快一些。但是，索引条目中涉及的任何VARCHAR都会抵消（抵消）由于使用TIN而使用TINYINT所带来的性能提升。

尽管如此，如果索引条目具有复合条目并且全部都是整数，则整数按字节排列越小，则越好且越快。

当数据库变得更大时，所有事情变得变得复杂：

• 维护时段需要扩大或重新安排
• 备份（一天结束时的完整备份成为荒谬的浪费时间，因此您需要差异备份或什至日志备份，并每周执行一次完整备份，也许每月一次）
• 性能维护成为一个耗时的工作（在数百万行的表上创建索引不会花费很短的时间来执行），并且需要重新安排时间，如果表很宽，情况会变得更糟...
• 而且通过网络传输该100Gb备份并不是我的小菜一碟-特别是如果网络（出于某种未知原因）在断开连接到75Gb标记时固执的话……（发生在我正在安装的设备上正在备份到网络上的映射驱动器-网络）...

与此相关的数据类型是什么？一切。如果使用的行大小大于必需的行数，则数据库页面将比需要的空间更早填充，或者如果行大小不能在该页面上记录多于一条的记录，则甚至浪费空间。结果是需要写入和读取更多的页面，更多的RAM内存用于缓存（更大的记录需要更大的内存）。并且由于您指定的数据类型大于磁盘所需的数据类型，因此索引将遭受相同的问题-特别是如果您将2个BIGINT列的主键群集在一起，因为创建的任何其他索引都会在其定义上隐式复制该主键。

如果您知道某个表中的某些列将具有数百万个行，甚至有一个小表可以将FK扩展到数百万行，则不需要4个字节的整数来存储数据，但是2个字节将足够-使用SMALLINT。如果范围在0-255之间的值足够，请使用TINYINT。是/否标志？有BIT。

尽管for tinyint与vs int有明显的区别，例如磁盘空间，页面拆分和维护时间，但for不会有任何区别varchar。

那么为什么不将所有文本字段都声明为varchar(4000)，因为它只会占用所需的空间？甚至可以保证您的数据将永远不会被截断。

答案当然是：

1. 说明您的意图（因为没人会理解为什么名称字段应为4000个字符）
2. 要进行验证，以确保没有人输入完整的传记作为名称。

这些完全相同的原因也适用tinyint。