MySQL 基本数据类型

前言

本来觉得这篇博客没必要写的，因为 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 的，也不知道具体应用场景，如果有使用这种写法的朋友可以留言告知具体在哪种场景下用到了这种写法。

MySQL 基本数据类型

标签：int   图片   官方   写法   select   基本数据   实际应用   str   根据