我应该为我的自动增量 ID 使用 MySQL 的 INT 大小
目前，我们对 30 多个表数据库中的所有自动增量 id 列使用 INT(21)*。
我们是一个博客网站，有存储成员、评论、博客文章等的表。
我很确定我们永远不会达到 INT(21) id 列的限制，并且想知道：
- 如果在我确定我们永远不需要它时使用 INT(21) 会浪费空间
- 如果是浪费，自动增量 id 列的建议大小是
*不是我的设计。我问这个问题是因为我正在考虑将其简化为 INT(10)。
Currently we're using INT(21)* for all autoincrement id columns in out 30+ table database.
We are a blogging site, and have tables storing members, comments, blog posts and the like.
I'm quite sure we will never reach the limit of our INT(21) id columns, and would like to know:
- If using INT(21) when I am sure we'll never need it is a waste of space
- If it is a waste, what the recommended size for an autoincrement id column is
*Not my design. I'm asking this because I'm considering reducing this to say, INT(10).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
括号内的值是显示宽度。
结论
INT(10)或INT(21)不会影响可存储的值。如果您确实有顾虑，可以轻松地将数据类型更改为 BIGINT，而据我所知，不会产生任何影响。我会查看在给定时期（即一个月）内创建了多少新记录&根据该历史记录查看需要多长时间才能达到最大 INT 值。The value within the brackets is the display width.
Conclusion
INT(10)orINT(21), doesn't impact the values that can be stored. If you really have a concern, the data type can easily be changed to be BIGINT with no repercussions that I'm aware of. I'd look at how many new records are being created in a given period (IE a month) & see how long it'll take to max out the INT value based on that history.请参阅此处了解每种 int 类型的限制： http://dev .mysql.com/doc/refman/5.0/en/numeric-types.html
请注意
INT(21) == INT(100000)。如果您指定字段应该用零填充，则括号中的数字只是填充了多少个零。一个无符号
int字段最多可以容纳 4294967295 条记录（请参阅上面的链接）。See here for the limit of each int type: http://dev.mysql.com/doc/refman/5.0/en/numeric-types.html
Note that
INT(21) == INT(100000). The number in brackets is just how many zeros are padded to it if you specify the field should be zero-padded.An unsigned
intfield can hold up to 4294967295 records (see link above).不用担心占用太多空间，空间很便宜。选择您知道不会超出的列类型。当您选择 Smallint 来节省空间时，您会踢自己一脚；当您的数据库无法容纳更多数据时，您会遇到问题。
Don't worry about taking too much space, space is cheap. Choose a column type that you know you won't exceed. You'll kick yourself when you choose smallint to save space and run into issues when your database won't hold anymore data.