MySQL：建立表时如何选择合适的字段类型

最近须要对表加一个字段，同时以为前期创建表的时候有点粗暴，没有加很对限制，好比有些字符串长度是有限制的，在建立表时字段也没有对其进行限制。因此想借着此次加字段对表字段也进行一个优化，在优化以前先看了点理论知识，理论指导实践

写在前面

选择合适的字段类型既能够节省空间，又能够在查询上提升效率，所以字段类型选择是很重要的。本篇文章将介绍经常使用字段类型：

• 整数类型
• 实数类型
• 字符串类型
• 日期和时间
• 枚举类型

整数类型

整数类型有TINYINT，SMALLINT，MEDIUMINT，INT，BIGINT，存储空间及数值范围以下表

类型	存储空间(单位为位)	数值范围
TINYINT	8	-128 ~ 127
SMALLINT	16	-32768 ~ 32767
MEDIUMINT	24	-8388608 ~ 8388607
INT	32	-2147483648 ~ 2147483647
BIGINT	64	太大了

数值范围为-2^(N-1) ~ 2^N， 其中N为存储空间大小

整数类型有可选的UNSIGNED属性，不容许出现负值。设置UNSIGNED属性可使正数的上限提升一倍，数值范围大小为 0 ~ 2^(N-1) + 2^N

通常选择最小的可以知足存储的类型就行，更小的数据类型一般更快，占用更少的磁盘、内存和CPU缓存。处理时须要的CPU周期也更少

实数类型

FLOAT

单精度浮点型，使用8位

DOUBLE

双精度浮点型，使用16位存储

DECIMAL

float和double进行计算时会发生精度损失，损精度损失缘由可参考这篇文章：老板，用float存储金额为何要扣我工资 须要精度计算的时候可使用DECIMAL，使用DECIMAL须要额外的空间和计算开销，所以当且仅当须要精度计算时才使用

字符串类型

1. VARCHAR和CHAR

varchar和char是很是很是经常使用的字符串类型

VARCHAR

VARCHAR用于存储变长字符串，使用该类型存储字符串时须要额外使用1或2个额外字节记录字符串的长度：

• 列的最大长度小于或等于255 => 使用1字节
• 列的长度大于255 => 使用2字节

适用VARCHAR做为存储类型的场景：

• 列更新不多 => 列常常更新容易产生页分裂
• 列长度非固定 => VARCHAR存储时只使用必要空间，所以会省空间

CHAR

CHAR用于存储定长字符串，在存储CHAR类型时，会删除全部的末尾空格

使用CHAR最为存储类型的场景

• 列几乎定长
• 列长度很短 => VARCHAR须要额外字节存储长度
• 列常常更新

2. BLOB和TEXT类型

BLOB和TEXT类型都是用来存储很大的数据，好比文章内容这些

BLOB

采用二进制方式存储， BLOB细分又能够分为TINYBLOB，SMALLBLOB，BLOB，MEDIUMBLOB， LONGBLOB

TEXT

采用字符方式存储，TEXT细分又能够分为TINYTEXT，SMALLTEXT，TEXT，MEDIUMTEXT， LONGTEXT

当BLOB和TEXT值太大时，InnoDB存储会使用外部存储区域来存储值，而后保存一个1~4字节的指针指向外部存储

日期和时间类型

经常使用的日期类型有DATETIME和TIMESTAMP

DATETIME

使用8字节存储，能够保存大范围的值，从1001~9999年

TIMESTAMP

使用4字节存储，保存范围比DATETIME小，从1970~2038年

对于须要存储更小粒度的日期和时间可使用DOUBLE或BIGINT，固然不是存储小粒度也可使用BIGINT

DATETIME和TIMESTAMP如何选择

以前曾由于时间类型搞出过线上慢查询，这篇文章记录了慢查询缘由：很高兴！终于踩到了慢查询的坑， 对于须要对时间进行范围查找、排序、分组等操做之类的建议使用BIGINT，若是对时间类型字段没有任何操做，建议使用TIMESTAMP，能够参考这篇文章：mysql数据库时间类型datetime、bigint、timestamp的查询效率比较
在stackoverflow下找到以下：

枚举类型

可使用枚举列代替经常使用的字符串类型，经过枚举能够限制值的取值范围

枚举使用

建立表语句：

CREATE TABLE `dataset_enum` (
  `name` varchar(48) DEFAULT NULL,
  `status` enum('NEW','UPLOADING','USING','DELETING') DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8
复制代码

插入语句：

insert into dataset_enum(name, status) values("t4", "DELETING")
复制代码

对于status字段底层存储的是整数而不是字符串，在底层会维护一个 数字 - 字符串的映射关系

查询语句并根据status字段进行排序：

select * from dataset_enum order by status;
复制代码

查询结果：

+------+-----------+
| name | status    |
+------+-----------+
| t1   | NEW       |
| t2   | UPLOADING |
| t4   | DELETING  |
+------+-----------+
复制代码

说明：

• 排序的结果是根据内部存储的整数来的而不是定义的字符串进行排序的
• 底层存储的是整数，根据映射关系转化为字符串，所以会有必定的开销

为何使用TINYINT而不用ENUM

以前建立表的时候对于经常使用字符串的代替选择的都是TINYINT类型，应用层在作转换。当看到ENUM类型时有点困惑，为何没选择使用ENUM而是TINY，网上查找了一下缘由，以下图：

总结缘由以下：

• 不方便迁移，可扩展性弱，如比较熟悉的PostgreSQL数据库就不支持ENUM类型
• ENUM字段添加或删除字符串时会进行表重构，这个操做很是耗时和耗性能
• 有坑 以以前的表dataset_enum为例插入数据：

  mysql> insert into dataset_enum values("t1", "NEW"), ("t2", 2);
  Query OK, 2 rows affected (0.01 sec)
  Records: 2  Duplicates: 0  Warnings: 0
  复制代码

  成功插入了数据 查询数据：

  mysql> select * from dataset_enum;
  +------+-----------+
  | name | status    |
  +------+-----------+
  | t1   | NEW       |
  | t2   | UPLOADING |
  +------+-----------+
  复制代码

  数值类型作转化之后也能够插入
• 没法与其余表作关联

---

参考文章：
Should I use the datetime or timestamp data type in MySQL?
8 Reasons Why MySQL's ENUM Data Type Is Evil 为何辣么多人喜欢用 tinyint而不用 enum? 《高性能MySQL》