tinyint(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!");