MySQL数据类型详解：数值、字符串、日期时间与JSON分类指南

阿麦

发布时间：2026-09-22 | 4人浏览过

原创

MySQL字段的数据类型决定了数据库能够保存什么内容、如何比较和计算这些内容，以及需要占用多少存储空间。实际建表时，最常用的类型可以归纳为四组：保存数量和金额的数值类型、保存文本和二进制内容的字符串类型、保存日期时间的时间类型，以及保存结构化动态数据的JSON类型。选择时不需要追求“越大越保险”，而应先看数据的含义，再确定范围、精度、长度以及是否需要参与计算和索引。

一、先理解MySQL数据类型是怎样分类的

一个字段应该使用什么类型，首先取决于它代表的是什么。例如用户年龄属于整数，商品价格需要精确的小数，用户名属于字符串，订单创建时间属于日期时间，而一组结构不固定的扩展属性则可能适合JSON。

从日常业务开发的角度，可以把常见MySQL数据类型理解为下面几类。

MySQL数据类型详解：数值、字符串、日期时间与JSON分类指南 — 图1：MySQL常用字段类型可以先按“数据代表什么”进行分类，再决定具体类型。

这种分类方式比死记所有类型名称更实用。比如看到“金额”，应该先想到精确数值，再在DECIMAL等类型中选择，而不是因为金额中存在小数就直接使用FLOAT。

二、数值类型：整数、定点数和浮点数分别什么时候用

MySQL中的数值类型主要解决三个问题：整数、要求精确的小数，以及允许近似表示的小数。这三类数据看起来都属于“数字”，实际用途差别很大。

1. 整数类型

常用整数类型包括TINYINT、SMALLINT、MEDIUMINT、INT和BIGINT。它们的主要区别是能够表示的数值范围以及占用的存储空间。

类型	典型用途	选择思路
`TINYINT`	状态、小范围数量	数值范围明确且很小时使用
`SMALLINT`	中小范围整数	比TINYINT范围更大，但不需要INT时使用
`MEDIUMINT`	介于SMALLINT和INT之间的数据	对空间较敏感且范围明确时考虑
`INT`	常规编号、计数、数量	通用整数场景中最常见
`BIGINT`	可能非常大的ID或累计值	明确可能超过INT范围时使用

例如商品库存不需要小数，可以定义为整数：

stock INT NOT NULL DEFAULT 0

如果字段从业务含义上不允许出现负数，可以根据实际需求考虑无符号整数：

stock INT UNSIGNED NOT NULL DEFAULT 0

不过不要只因为“现在不会出现负数”就机械地给所有字段添加UNSIGNED。数据库设计还需要考虑未来是否存在差额、修正值或其他需要负数的场景。

2. 金额优先考虑DECIMAL

价格、余额、结算金额等数据通常要求十进制意义上的精确结果，这时更适合使用DECIMAL。

例如：

price DECIMAL(10,2) NOT NULL

这里的DECIMAL(10,2)表示总共最多保存10位十进制数字，其中2位位于小数点后。因此它适合类似下面的金额：

19.90
1280.00
99999999.99

如果是账户余额、订单金额或财务统计，不应仅仅因为数据有小数就默认选择FLOAT或DOUBLE。浮点数使用的是近似表示方式，某些十进制小数无法被二进制浮点格式精确表达。

3. FLOAT和DOUBLE适合允许近似值的计算

FLOAT和DOUBLE适合科学计算、测量值、统计数据等允许存在浮点近似误差的场景。通常DOUBLE能够提供比FLOAT更高的精度，但也需要更多空间。

例如一个用于记录传感器测量值的字段，可以使用：

temperature DOUBLE

选择数值类型时，可以按照下面的顺序判断，而不是从类型名称反推用途。

三、字符串类型：CHAR、VARCHAR、TEXT怎么选

字符串类型用于保存名称、标题、邮箱、URL、文章正文等文本信息。常见选择并不是简单的“短字符串用VARCHAR，长字符串用TEXT”，还要看长度是否固定、是否需要频繁索引以及字段的实际语义。

1. CHAR适合长度相对固定的数据

CHAR(n)适合长度固定或基本固定的字符串。例如某些固定格式代码可以考虑：

country_code CHAR(2)

如果一个字段大部分数据长度变化很大，则通常没有必要为了固定长度而使用CHAR。

2. VARCHAR是业务表中最常见的文本类型之一

用户名、文章标题、邮箱、文件路径等长度会变化但通常存在合理上限的内容，往往适合使用VARCHAR。

username VARCHAR(50) NOT NULL,
email VARCHAR(255) NOT NULL,
title VARCHAR(200) NOT NULL

这里的长度应该根据业务约束确定，而不是看到VARCHAR就统一定义成某个很大的值。

例如用户名规定最多50个字符，使用VARCHAR(50)能够直接表达这一业务限制。相比之下，把所有字符串都定义成非常大的VARCHAR，会使表结构失去对数据含义的表达能力，同时还可能影响索引设计。

3. TEXT适合较长正文

对于文章内容、备注、详情描述等长度可能明显超过普通标题和名称的数据，可以考虑TEXT系列类型。

content TEXT

MySQL还提供不同容量级别的TEXT类型，例如TINYTEXT、TEXT、MEDIUMTEXT和LONGTEXT。实际选择时应根据可能出现的数据长度确定，而不是默认使用容量最大的类型。

4. BLOB保存的是二进制数据

TEXT主要保存字符数据，而BLOB系列用于保存二进制数据。如果内容本质上不是文本，例如某些二进制文件内容，就属于另一类问题。

不过在Web系统中，大型图片、视频和附件通常更常见的做法是保存到文件系统或对象存储中，数据库只记录路径、URL、对象键和元数据。是否直接把二进制内容放入数据库，需要结合备份、访问方式、文件规模和系统架构判断。

5. ENUM和SET不要仅仅因为“写起来方便”就使用

MySQL还提供ENUM和SET。ENUM允许字段从预先定义的一组值中选择一个，而SET允许选择其中多个。

例如：

status ENUM('draft', 'published', 'disabled')

这种方式能够直接在字段定义中约束取值，但如果业务状态频繁变化，修改枚举定义会增加数据库结构变更成本。因此应根据业务稳定程度决定是否使用。

四、日期时间类型：不要把时间全部保存成VARCHAR

日期和时间如果需要排序、筛选、计算或使用MySQL的日期函数，应优先使用专门的时间类型，而不是把2026-09-22 16:30:00这样的内容保存到VARCHAR中。

常见类型主要有DATE、TIME、DATETIME、TIMESTAMP和YEAR。

1. DATE只保存日期

如果业务只需要“哪一天”，而不关心具体时分秒，就可以使用：

birthday DATE

典型值类似：

1995-08-18

2. TIME用于时间或时间间隔

只需要表示时间部分时可以考虑TIME。例如某些营业时长、时间值或持续时间场景可以使用TIME，但具体使用前需要确认业务语义是否与MySQL TIME类型相匹配。

3. DATETIME适合保存明确的日期和时间

文章发布时间、预约时间等需要完整年月日和时分秒的信息，可以使用DATETIME：

published_at DATETIME

4. TIMESTAMP与时区处理有关

TIMESTAMP同样可以表示日期和时间，但它与MySQL会话时区之间存在转换关系。这一点是它和DATETIME在实际使用中的重要区别之一。

简单来说，如果业务需要记录一个统一的时间点，并希望数据库在不同时区的会话中进行相应转换，可以研究TIMESTAMP是否符合系统设计；如果希望保存的日期时间值本身保持不变，则DATETIME往往更容易理解。

注意：时间类型的选择不仅是“DATETIME和TIMESTAMP哪个更省空间”的问题。跨时区系统还需要统一应用层、数据库连接和服务器的时区策略，否则同一个时间点可能在不同环节产生理解偏差。

五、JSON类型：适合动态属性，但不是“万能字段”

MySQL提供原生JSON类型，可以保存JSON对象、数组以及其他合法JSON值。与直接把JSON文本保存到普通VARCHAR或TEXT中相比，JSON字段能够让数据库识别其结构，并使用相应的JSON函数进行读取和处理。

例如商品可能存在一些不固定的扩展属性：

{
  "color": "black",
  "memory": "16GB",
  "ports": ["USB-C", "HDMI"]
}

可以建立一个JSON字段：

attributes JSON

插入示例数据：

INSERT INTO products
    (name, price, attributes)
VALUES
    (
        '示例笔记本',
        5999.00,
        JSON_OBJECT(
            'color', 'black',
            'memory', '16GB',
            'ports', JSON_ARRAY('USB-C', 'HDMI')
        )
    );

读取JSON内部属性时，可以使用MySQL提供的JSON操作方式。例如获取color：

SELECT attributes->>'$.color' AS color
FROM products;

示例结果：

black

什么时候适合JSON

JSON比较适合下面这类数据：

不同记录可能拥有不同扩展属性；
属性数量和名称不是完全固定；
这些属性属于主记录的辅助信息；
需要保留对象或数组这样的层级结构。

什么时候不应该为了省事全部使用JSON

如果字段是稳定、核心并且经常用于查询，例如商品名称、用户ID、价格、订单状态，就更适合建立明确的普通字段。

例如下面这种设计通常不够合理：

CREATE TABLE products (
    id BIGINT PRIMARY KEY,
    data JSON
);

然后把商品名称、价格、库存、状态和创建时间全部放入data中。这样虽然字段看起来少了，但核心数据的约束、索引、查询以及表结构可读性都会变得更加复杂。

更自然的设计是：

CREATE TABLE products (
    id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
    name VARCHAR(200) NOT NULL,
    price DECIMAL(10,2) NOT NULL,
    stock INT UNSIGNED NOT NULL DEFAULT 0,
    status TINYINT NOT NULL DEFAULT 1,
    attributes JSON,
    created_at DATETIME NOT NULL,
    PRIMARY KEY (id)
);

这里把稳定字段拆成普通列，把结构不固定的扩展属性交给JSON处理，两者各自承担适合自己的职责。

六、BOOLEAN实际上应该怎样理解

MySQL允许在字段定义中写BOOLEAN或BOOL，但在MySQL的数据类型体系中，它们是TINYINT(1)的同义表示。

例如：

is_active BOOLEAN NOT NULL DEFAULT TRUE

在应用程序里，可以把0理解为false，把非0值理解为true。对于确实只有“开/关”“是/否”两个状态的字段，这种写法具有较好的可读性。

如果字段实际存在多个状态，例如“待审核、已发布、已下架”，就不要把它设计成布尔类型，而应使用能够明确表达多个状态的字段。

七、不要把“编号”一律理解成数值

判断字段类型时，一个很容易出现的错误是看到内容由数字组成，就认为必须使用INT。

例如：

订单流水号；
手机号；
邮政编码；
身份证件编号；
带前导零的业务编码。

这些内容虽然可能主要由数字字符组成，但通常并不用于数学运算。“编号”和“数值”不是同一个概念。

例如一个代码值：

如果保存为整数，它会变成：

原有的前导零已经失去。因此，如果业务关注的是字符串形式本身，通常应该根据实际长度使用CHAR或VARCHAR，而不是仅根据字符看起来像数字就选择整数。

八、一个完整建表示例：把不同类型放到真实结构中理解

假设现在要建立一个简单的商品表，需要保存商品ID、名称、价格、库存、是否上架、上架日期、创建时间以及扩展属性。

可以写成：

CREATE TABLE products (
    id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
    name VARCHAR(200) NOT NULL,
    price DECIMAL(10,2) NOT NULL,
    stock INT UNSIGNED NOT NULL DEFAULT 0,
    is_enabled BOOLEAN NOT NULL DEFAULT TRUE,
    online_date DATE NULL,
    attributes JSON NULL,
    created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
    PRIMARY KEY (id)
);

逐个看这些字段为什么这样设计：