我记得在某处读到过使用 Int32 更好（在性能方面），即使您只需要 Byte。它仅适用于（据说）您不关心存储的情况。这有效吗？
例如，我需要一个变量来保存一周中的某一天。我是吗
int dayOfWeek;
或
byte dayOfWeek;
编辑： 伙计们，我知道 DayOfWeek 枚举。这个问题是关于其他的。
【问题讨论】：
通常是的，32 位整数的性能会稍好一些，因为它已经为本地 CPU 指令正确对齐。仅当您实际需要存储该大小的内容时，才应使用较小的数字类型。
【讨论】：
byte[]（八位字节数组）而不是int[] 或uint[] 的形式给出，因此byte 似乎在那种情况。当然，如果您使用int[]，您将自己限制在数据长度是 32 位（而不是 8 位）的整数倍的情况下，这可能是一个问题或一个优势，具体取决于上下文。跨度>
您应该使用 DayOfWeek 枚举，除非有充分的理由不这样做。
DayOfWeek day = DayOfWeek.Friday;
解释一下，因为我被否决了：
您的代码的正确性几乎总是比性能更重要，尤其是在我们谈论的差异很小的情况下。如果使用枚举或表示数据语义的类（无论是 DayOfWeek 枚举，还是其他枚举，或 Gallons 或 Feet 类）使您的代码更清晰或更易于维护，它将帮助您达到可以安全优化。
int z;
int x = 3;
int y = 4;
z = x + y;
这可以编译。但是没有办法知道它是否在做任何理智的事情。
Gallons z;
Gallons x = new Gallons(3);
Feet y = new Feet(4);
z = x + y;
这不会编译，即使看着它也很明显为什么不 - 将加仑添加到英尺 没有意义。
【讨论】：
我的默认立场是尝试使用强类型来为值添加约束——你事先知道这些。因此，在您的示例中，最好使用byte dayOfWeek，因为它更接近您想要的值范围。
这是我的推理；以存储和传递日期的年份部分为例。年份部分 - 当考虑包括 SQL Server DateTimes 在内的系统其他部分时，限制为 1753 到 9999（注意 C# 的 DateTime 可能范围不同！）因此，short 涵盖了我可能的值，如果我尝试通过在代码编译之前，编译器会警告我任何更大的东西。不幸的是，在这个特定的示例中，C# DateTime.Year 属性将返回一个 int - 因此如果我需要传递结果，则迫使我强制转换结果，例如DateTime.Now.Year 进入我的功能。
这个起始位置是考虑到数据的长期存储，假设“数百万行”和磁盘空间 - 尽管它很便宜（当您托管并运行 SAN 或类似设备时，它的成本要低得多)。
在另一个数据库示例中，我将使用较小的类型，例如 byte (SQL Server tinyint) 作为查找 ID，我确信不会有很多查找类型，一直到 long (SQL Server bigint) 作为 id可能是更多的记录。即涵盖交易记录。
所以我的经验法则：
为了清楚起见，通过将列类型从 bigint 缩减为更小的类型，DB 存储的缩减速度往往没有您预期的那么快。这既是因为对字边界的填充和数据库内部的页面大小问题。但是，您可能会在数据库中多次存储每个数据项，可能是通过存储更改时的历史记录，并保留最近几天的备份和日志备份。因此，节省百分之几的存储需求将长期节省存储成本。
我从未亲身经历过字节与整数的内存性能问题，但我浪费了数小时不得不重新分配磁盘空间并使实时服务器完全停止，因为没有人可用监控和管理这些事情。
【讨论】：
使用整数。计算机内存由“字”寻址，字长通常为 4 个字节。这意味着如果您想从内存中获取一个字节的数据，CPU 必须从 RAM 中检索整个 4 字节字，然后执行一些额外的步骤来隔离您感兴趣的单个字节。关于性能，CPU 检索整个单词并完成它会容易得多。
实际上，就性能而言，您不会注意到两者之间的任何差异（除非在极少数的极端情况下）。这就是我喜欢使用 int 而不是 byte 的原因，因为您可以存储更大的数字而几乎不会受到任何惩罚。
【讨论】：
【讨论】：
存储量使用byte，cpu性能使用int。
【讨论】：