前言

本來覺得這篇博客沒必要寫的，因為 MySQL 官方介紹的很詳細。但是最近在設計表的時候遇到一些問題并不是簡單的看官方介紹就能夠解決的，所以，在這里想給大家看一下。

數據類型

整型

首先，我們看一下 MySQL 5.7 官方給出的每種整數類型所需要的存儲空間和數值范圍：

這里要注意的是，從實際應用角度，我們一定要根據實際情況選擇最合適的數據類型。 例如：

• 一個表示布爾類型的 0 和 1 的列，選擇 TINYINT(1) 就足夠了，但是如果你使用了存儲字節數大于 TINYINT 的數據類型就是設計不合理。

數據庫和內存不同，以 Java 為例，可以使用 byte 類型的地方使用了 long 類型問題不大，因為絕大多數的對象在程序中都是短命對象，方法執行完畢這塊內存區域就被釋放了，7 個字節實際上不存在浪不浪費一說。但是數據庫作為一個存儲系統，8 字節的 BIGINT 據的空間是實實在在的。

整型（N）形式

先看一下 MySQL 5.7 官方介紹

對于整數類型，M 表示最大顯示寬度。最大顯示寬度為 255. 顯示寬度與類型可包含的值范圍無關

所以對于整型（N）這種形式，我們只要明白兩點：

• 無論 N 是多少和該類型所占字節數無關

• N 表示的是顯示寬度，不足的用 0 補足，超過的無視長度而直接顯示整個數字，但這要整型設置了 unsigned zerofill 才有效

下面舉個例子：

DROP TABLE IF EXISTS test; CREATE TABLE test (a INT(5),b INT(5) UNSIGNED,c INT(5) UNSIGNED ZEROFILL,d INT(8) UNSIGNED ZEROFILL ) ENGINE=InnoDB DEFAULT CHARSET=utf8;INSERT INTO test VALUES(1,1,1,1111111111);SELECT * FROM test;

從上面的兩點，我們應該預期結果應該是 1,1,00001,1111111111

我們看一下結果：

不符合預期是吧，因為這個問題我也有過困擾，后來查了一下貌似是 Navicat 工具本身的問題，我們使用控制臺就不會有這個問題了；

不過實際工作場景中反正我是沒有碰到過指定 zerofill 的，也不知道具體應用場景，如果有使用這種寫法的朋友可以留言告知具體在哪種場景下用到了這種寫法。

轉載于:https://www.cnblogs.com/tkzL/p/11366948.html

總結

以上是生活随笔為你收集整理的MySQL 基本数据类型的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。