在性能方面，int 几乎在所有情况下都更快.CPU 旨在有效处理 32 位值.

较短的值处理起来很复杂.例如，要读取单个字节，CPU 必须读取包含它的 32 位块，然后屏蔽掉高 24 位.

要写入一个字节，它必须读取目标 32 位块，用所需的字节值覆盖低 8 位，然后再次写回整个 32 位块.

当然，在空间方面，您可以通过使用较小的数据类型来节省一些字节.因此，如果您正在构建一个包含几百万行的表，那么较短的数据类型可能值得考虑.(这可能也是您应该在数据库中使用较小数据类型的好理由)

在正确性方面，int 不会轻易溢出.如果您认为您的值将适合一个字节，然后在未来的某个时刻对代码进行一些看似无害的更改意味着将更大的值存储到其中怎么办?

这些是为什么 int 应该成为所有整数数据的默认数据类型的一些原因.如果您确实要存储机器字节，则仅使用字节.仅当您处理实际指定 16 位整数值的文件格式或协议或类似格式时才使用 shorts.如果您只是处理一般的整数，请将它们设为整数.

I have found a few threads in regards to this issue. Most people appear to favor using int in their c# code accross the board even if a byte or smallint would handle the data unless it is a mobile app. I don't understand why. Doesn't it make more sense to define your C# datatype as the same datatype that would be in your data storage solution?

My Premise: If I am using a typed dataset, Linq2SQL classes, POCO, one way or another I will run into compiler datatype conversion issues if I don't keep my datatypes in sync across my tiers. I don't really like doing System.Convert all the time just because it was easier to use int accross the board in c# code. I have always used whatever the smallest datatype is needed to handle the data in the database as well as in code, to keep my interface to the database clean. So I would bet 75% of my C# code is using byte or short as opposed to int, because that is what is in the database.

Possibilities: Does this mean that most people who just use int for everything in code also use the int datatype for their sql storage datatypes and could care less about the overall size of their database, or do they do system.convert in code wherever applicable?

Why I care: I have worked on my own forever and I just want to be familiar with best practices and standard coding conventions.

Performance-wise, an int is faster in almost all cases. The CPU is designed to work efficiently with 32-bit values.

Shorter values are complicated to deal with. To read a single byte, say, the CPU has to read the 32-bit block that contains it, and then mask out the upper 24 bits.

To write a byte, it has to read the destination 32-bit block, overwrite the lower 8 bits with the desired byte value, and write the entire 32-bit block back again.

Space-wise, of course, you save a few bytes by using smaller datatypes. So if you're building a table with a few million rows, then shorter datatypes may be worth considering. (And the same might be good reason why you should use smaller datatypes in your database)

And correctness-wise, an int doesn't overflow easily. What if you think your value is going to fit within a byte, and then at some point in the future some harmless-looking change to the code means larger values get stored into it?

Those are some of the reasons why int should be your default datatype for all integral data. Only use byte if you actually want to store machine bytes. Only use shorts if you're dealing with a file format or protocol or similar that actually specifies 16-bit integer values. If you're just dealing with integers in general, make them ints.