mysql中TINYINT的取值范围

项目场景：

最近在开发过程中，看见表设计中是thinyint字段，但对于它的范围产生了好奇

---

问题描述：

当我们填写超过128数值的时候，该字段就会报以下错误

Cause:com.mysql.jdbc.MysqlDataTruncation:Data truncation:Out of range value for column 'priority' at row 1;

---

原因分析：

从 -2^7 (-128) 到 2^7 - 1 (127) 的整型数据。存储大小为 1 个字节(不设置为UNSIGNED 无符号类型)。
所以建表的时候，真实效果其实只为tinyint(3),哪怕你建tinyint(100)，他最大还是3位这么多。

---

在这里给大家科普一下tinyint为什么会产生这样的限制

在MySQL的数据类型中，Tinyint的取值范围是：带符号的范围是-128到127。无符号的范围是0到255（可参考官方《MySQL 5.1参考手册》

Tinyint占用1字节的存储空间，即8位（bit）。那么Tinyint的取值范围怎么来的呢？
先看无符号的情况。无符号的最小值即全部8位（bit）都为0，换算成十进制就是0，所以无符号的Tinyint的最小值为0.无符号的最大值即全部8bit都为1，11111111，换算成十进制就是255.这很好理解。
有符号的Tinyint的取值范围是怎么来的呢？在计算机中，用最高位表示符号。0表示正，1表示负，剩下的表示数值。那么有符号的8bit
最小值：
　　1　　1　　1　　1　　1　　1　　1　　1 = -127 (表示负值)
最大值：
　　0　　1　　1　　1　　1　　1　　1　　1 = +127（表示正值）

怎么有符号的最小值是-127，而不是-128呢？这就是本文要说的关键地方了，在计算机中，表示负值是用补码
为什么有符号的TINYINT的最小值是-128？虽然“-0”也是“0”，但根据正、反、补码体系，“-0”的补码和“+0”是不同的，这样就出现两个补码代表一个数值的情况。为了将补码与数字一一对应，所以人为规定“0”一律用“+0”代表。同时为了充分利用资源，就将原来本应该表示“-0”的补码规定为代表-128。

---

额外进行知识点拓展
mysql中int、bigint、smallint 和 tinyint的主要区别简单介绍

最近使用mysql数据库的时候遇到了多种数字的类型，主要有int,bigint,smallint和tinyint。其中比较迷惑的是int和smallint的差别，写在博客中做个记录：
使用整数数据的精确数字数据类型。
bigint
从 -2^63 (-9223372036854775808) 到 2^63-1 (9223372036854775807) 的整型数据（所有数字）。存储大小为 8 个字节。

int
从 -2^31 (-2,147,483,648) 到 2^31 – 1 (2,147,483,647)
的整型数据（所有数字）。存储大小为 4 个字节。int 的 SQL-92 同义字为 integer。

smallint
从 -2^15 (-32,768) 到 2^15 – 1 (32,767) 的整型数据。存储大小为 2 个字节。

tinyint
从 0 到 255 的整型数据。存储大小为 1 字节。
补充:
在支持整数值的地方支持 bigint 数据类型。但是，bigint 用于某些特殊的情况，当整数值超过 int 数据类型支持的范围时，就可以采用 bigint。在 SQL Server 中，int 数据类型是主要的整数数据类型。
在数据类型优先次序表中，bigint 位于 smallmoney 和 int 之间。
只有当参数表达式是 bigint 数据类型时，函数才返回 bigint。SQL Server 不会自动将其它整数数据类型（tinyint、smallint 和 int）提升为 bigint。
int(M) 在 integer 数据类型中，M 表示最大显示宽度。在 int(M) 中，M 的值跟 int(M) 所占多少存储空间并无任何关系。和数字位数也无关系 int(3)、int(4)、int(8) 在磁盘上都是占用 4 btyes 的存储空间。

解决方案：

解决方法主要有三个
1.修改数据表字段（改为int或者其他类型）
2.前端输入框进行校验，超过数值则进行弹框提示（不友好）
3.后端数值进行校验，不符合则抛出异常提示（我用的第三种方式）

Assert.isTrue(!(rule.getPriority()!= null && rule.getPriority()>100),"支持最大优先级数为100!");