首先在吐槽这个现象前,我先说下我们该篇的内容。
什么时候是 ***-2147483648到 2147483647 ***
什么时候是 0 到4294967295
int(1) 就只能存入 0,1,2,3,4,5,6,7,8,9 吗?
是这样理解??? 我存个10不行?
可能对这些概念很清晰的人会觉得这篇文章没有意义,是的。我一开始直到刚才我还是这样认为。
但是刚刚我身边的 研发们无意讨论这个事情,我才知道,原来不是应届生,是很多搞了很多年的人原来都没搞明白这些东西。
那么我猜测是不是还有很多兄弟们是没弄清晰的, 科普性的文章非常有必要。
**java **
int 的 范围 :
首先 int 4 字节 ;
一个字节 8位, 4×8 =32 位 ;
所以范围大小是 -2^31~2^31 -1 (-2147483648 ~ 2147483647) 。
mysql
int 的 范围 :
首先 int 4字节 ;
一个字节 8位, 4×8 =32 bit ;
所以范围大小是 -2^31~2^31-1 (-2147483648 ~ 2147483647)
注意了,对于mysql来说,int 默认是 这样的。
但是还存在 unsigned(无符号) int ,什么意思呢,也就是无符号,将负的范围分配到正去了,所以 unsigned(无符号) int 的范围大小 是 0 到4294967295 。
接下来到了很无语的 int(1) 环节 。。
首先我先说结论, int (1) 在mysql 里面 是指**显示 长度 !!! **
**跟存值范围没半毛钱关系 !****跟存值范围没半毛钱关系 !**跟存值范围没半毛钱关系 !
建表 test ,表结构 如 :
存值, num 直接存入int (有符号) 的最大值 : 2147483647
INSERT INTO test
(num
) VALUES (2147483647);
可以看到正常存储, 而并不是说 int(1) 就 是 只能 存 1位整数............ 希望之前还懵的人从此刻起,必须要纠正这个观念了。 对于int类型,不要有这种错误的理念了!!!
ps : 存入一下更大的值 2147483648 ,可以看到提示超过范围了 。
ps: 包括我身边的同事, 还会顺口说一句, 10够用了 ,11够用了之类的话.......
也是让人很无语呢。
其实这10和11 来源也是有说法的,记得前文我说的,对于mysql 创建int 类型,默认就是有符号。 也就是说范围在 -2147483648 ~ 2147483647 。
2147483647 长度 10
-2147483648 长度 11
所以 int (显示长度) 弄 int (10 ) 和 int(11) 自然就知道是啥意思了。
那如果我就不用负数,要弄成 int (无符号)使用 ,怎么操作?
alter test modify num int unsigned;
可以看到默认帮我们 int 改成无符号的 int时候,是int (10) ,这是最合理的。为什么,还是因为这个显示长度的概念, 无符号的int 范围在 0 ~ 4294967295
4294967295 长度 10 ;
OK,我就是要违反这个默认给的10 , 我改成 int(1) :
alter test modify num int(1) unsigned;
然后随便插入一个值, 12345678 :
insert into test (num) values (12345678);
没错,对于存在根本没影响。
所以就是说, 我们要知道
**int 类型字段 ,在mysql 里面 ,括号后面的 数字, 跟存储的int 数值 范围 **
半毛钱关系没有!!!
那至于就是想用的比较 安心一点(强迫症) ,
那如果是 默认int (默认是有符号),那你就int(11) 好了;
如果是 无符号 unsigned int ,那你就int (10) 好了。
但是我最后还是很倔强提一句,记住,半毛钱关系没有!
最后给大家说一哈几个小事,
① 最好在建表的时候就考虑好 int字段是有符号还是无符号,或者说最大想要存入的值的范围。
因为如果你一开始设置无符号 unsigned int ,存入了 大于 2147483647(有符号int的最大值),然后想调整 int字段 从 无符号变成有符号, 这时候会报错、
② int 有符号不够用,还可以用 bigint 8字节,
8×8=64 位 ,-2^63~2^63-1 (-9223372036854775808~9223372036854775807)
③ navicat上面 看 只显示3位长度 这件事,不必纠结这个navicat
navicat 操作界面 :
官方也给过解释:
MySQL Server 8.0.17 deprecated the display width for the TINYINT, SMALLINT, MEDIUMINT, INT, and BIGINT data types when the ZEROFILL modifier is not used, and MySQL Server 8.0.19 has removed the display width for those data types from results of SHOW CREATE TABLE, SHOW CREATE FUNCTION, and queries on INFORMATION_SCHEMA.COLUMNS, INFORMATION_SCHEMA.ROUTINES, and INFORMATION_SCHEMA.PARAMETERS (except for the display width for signed TINYINT(1)). This patch adjusts Connector/J to those recent changes of MySQL Server and, as a result, DatabaseMetaData, ParameterMetaData, and ResultSetMetaData now report identical results for all the above-mentioned integer types and also for the FLOAT and DOUBLE data types. (Bug #30477722)
从8.0.17版本开始,TINYINT, SMALLINT, MEDIUMINT, INT, and BIGINT类型的显示宽度将失效。
好吧,该篇就到这。
版权说明 : 本文为转载文章, 版权归原作者所有 版权申明
原文链接 : https://blog.csdn.net/qq_35387940/article/details/123325009
内容来源于网络,如有侵权,请联系作者删除!