对于该数据，最有效的 MySQL 列类型是什么？
我有几个表，每个表都有一些非常标准的数据。有人可以告诉我该数据的最佳列类型来帮助我优化它们吗？他们旁边的是我目前拥有的。
Number (max length 7) --> MEDIUMINT(8) Unsigned
Text (max length 30) --> VARCHAR(30)
Text (max length 200) --> VARCHAR(200)
Email Address (max length 200) --> VARCHAR(200)
Number (max length 4) --> SMALLINT(5) Unsigned
Number (either 0 or 1) --> TINYINT(1) Unsigned
Text (max length 500) --> TEXT
有什么建议吗？我只是猜测，所以我知道其中一些是错误的......
I have several tables with some pretty standard data in each. Can somebody help me optimize them by telling me the best column types for this data. Whats beside them is what I have currently.
Number (max length 7) --> MEDIUMINT(8) Unsigned
Text (max length 30) --> VARCHAR(30)
Text (max length 200) --> VARCHAR(200)
Email Address (max length 200) --> VARCHAR(200)
Number (max length 4) --> SMALLINT(5) Unsigned
Number (either 0 or 1) --> TINYINT(1) Unsigned
Text (max length 500) --> TEXT
Any suggestions? I'm just guessing with this so I know some of them are wrong...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
抱歉，这不是您问题的直接答案，但我认为这需要指出。我认为您可能误解了列类型后面括号中的整数的用途。
对于 VARCHAR 类型，您可能已经知道，它限制最大长度。但是，它不会影响用于存储特定字符串的字节数。长度为 5 的字符串无论存储在
VARCHAR(100)还是VARCHAR(200)中都需要相同数量的字节存储。对于整数类型，该数字与存储的字节数完全无关。它是显示宽度，这是别的东西。请参阅手册：
Sorry that this isn't a direct answer to your question but I think this needs pointing out. I think you may have misunderstood the purpose of the integer in brackets after the column type.
For
VARCHARtypes, as you probably already know, it restricts the maximum length. However it doesn't affect the number of bytes used for storage of a specific string. A string of length 5 will require the same number of bytes storage whether it is stored in aVARCHAR(100)or aVARCHAR(200).For integral types the number has nothing at all to do with the number of bytes of storage. It is the display width, which is something else. See the manual:
那应该是一个布尔值。
That should be a Boolean.
你已经说得很明智了。
请注意，您无法对列类型进行任何优化。使用索引即可。
You've got it pretty sensible already.
Please note, you can't optimize anything with column types. With indexes you do.
取决于你对“高效”的定义。就速度而言，CHAR 可能比 VARCHAR 更快（因为每行最终的长度相同，使得查找给定记录变得简单）。但所有字段都必须有固定长度，否则就不用担心。
Depends on your definition of "efficient". For speed, CHAR can be faster than VARCHAR (since each row ends up the same length, making it simple to seek to a given record). But all of your fields have to have fixed lengths, or don't bother.