当我知道该值不会超过 255 时，设置tinyint 字段是否有优势？
我应该选择尽可能小的数据类型，或者如果我存储值 1，那么 col 数据类型是什么并不重要，并且该值将占用相同的内存大小？
问题还在于，因为我总是必须转换它并在应用程序中使用。
更新
我认为如果值为“a”，则 varchar(1) 和 varchar(50) 的内存大小相同，我认为 int 和tinyint 是相同的，根据我理解的答案，它不是，是吗？
Should I choose the smallest datatype possible, or if I am storing the value 1 for example, it doesn't matter what is the col datatype and the value will occupy the same memory size?
The question is also, cuz I will always have to convert it and play around in the application.
UPDATE
I think that varchar(1) and varchar(50) is the same memory size if value is "a", I thought it's the same with int and tinyint, according to the answers I understand it's not, is it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
始终选择尽可能最小的数据类型。 SQL 无法猜测您想要的最大值是多少，但一旦您告诉它数据类型，它就可以优化存储和性能。
回答您的更新：
varchar确实只占用您使用的空间，因此当您说字符“a”将占用 1 个字节（拉丁编码）时，您是对的您选择的varchar字段有多大。 SQL 中任何其他类型的字段都不会出现这种情况。但是，如果将所有内容都设为 varchar 字段，则可能会为了空间而牺牲效率。如果所有内容都是固定大小的字段，那么 SQL 可以执行简单的常量时间乘法来查找您的值（如数组）。如果其中有 varchar 字段，那么找出数据存储位置的唯一方法是遍历所有先前的字段（如链接列表）。
如果您刚开始使用 SQL，那么我建议您远离 varchar 字段，除非您期望字段有时包含非常少量的文本，有时包含非常大量的文本（例如博客文章）。需要经验才能知道何时使用可变长度字段才能达到最佳效果，即使我大多数时候也不知道。
Always choose the smallest data type possible. SQL can't guess what you want the maximum value to be, but it can optimize storage and performance once you tell it the data type.
To answer your update:
varchardoes take up only as much space as you use and so you're right when you say that the character "a" will take up 1 byte (in latin encoding) no matter how large avarcharfield you choose. That is not the case with any other type of field in SQL.However, you will likely be sacrificing efficiency for space if you make everything a varchar field. If everything is a fixed-size field then SQL can do a simple constant-time multiplication to find your value (like an array). If you have varchar fields in there, then the only way to find out where you data is stored it to go through all the previous fields (like a linked list).
If you're beginning SQL then I advise just to stay away from varchar fields unless you expect to have fields that sometimes have very small amounts of text and sometimes very large amounts of text (like blog posts). It takes experience to know when to use variable length fields to the best effect and even I don't know most of the time.
这是系统设计特有的性能考虑因素。一般来说，Sql Server 数据页中容纳的数据越多，性能就越好。
Sql Server 中一页是 8k。使用小整数而不是整数将使您能够将更多数据放入单个页面中，但您必须考虑它是否值得。如果您要每分钟提供数千次点击，那么可以。如果这是一个业余爱好项目或者只有几十个用户会看到的东西，那么这并不重要。
It's a performance consideration particular to the design of your system. In general, the more data you can fit into a page of Sql Server data, the better the performance.
One page in Sql Server is 8k. Using tiny ints instead of ints will enable you to put more data into a single page but you have to consider whether or not it's worth it. If you're going to be serving up thousands of hits a minute, then yes. If this is a hobby project or something that just a few dozen users will ever see, then it doesn't matter.
优点是存在，但可能并不重要，除非您有很多行并且执行操作丢失。将会有性能改进和更小的存储空间。
The advantage is there but might not be significant unless you have lots of rows and performs los of operation. There'll be performance improvement and smaller storage.
传统上在页面大小上节省的每一位都意味着一点点速度的提高：更窄的行意味着每页更多的行，这意味着更少的内存消耗和更少的 IO 请求，从而带来更好的速度。然而，使用 SQL Server 2008 页面压缩，事情开始变得模糊。压缩算法可以将 4 字节整数压缩为小于 255 的值，甚至小于一个字节。
行压缩算法将在单个字节上存储 4 字节 int 127 以下的值（int 有符号），32768 以下的值为 2 个字节，依此类推。
然而，鉴于良好的压缩功能仅在企业版服务器上可用，因此保持使用尽可能最小的数据类型的习惯是有意义的。
Traditionally every bit saved on the page size would mean a little bit of speed improvement: narrower rows means more rows per page, which means less memory consumed and fewer IO requests, resulting in better speed. However, with SQL Server 2008 Page compression things start to get fuzzy. The compression algorithm may compress 4 byte ints with values under 255 on even less than a byte.
Row compression algorithms will store a 4 byte int on a single byte for values under 127 (int is signed), 2 bytes for values under 32768 and so on and so forth.
However, given that the nice compression features are only available on Enterprise Edition servers, it makes sense to keep the habit of using the smallest possible data type.