MySQL表中的每一列都会有一个明确的字段类型，字段类型不仅决定该列能够保存什么格式的数据，还会影响磁盘占用、索引性能以及数据校验行为。把MySQL的字段类型按照存储内容划分，可以分为数值类型、字符串类型以及日期时间类型三大类，每一类又包含若干具体类型，分别适用于不同的业务数据。合理选择字段类型是表结构设计的第一步，它直接关系到后续查询是否能命中索引、数据是否会出现精度误差，以及表在数据量增长后是否会过度膨胀。
数值类型的分类与选用
数值类型用于保存整数和小数，是业务表中最常见的一类字段。整数类型按照占用字节数的不同，可以进一步划分为 TINYINT、SMALLINT、INT 和 BIGINT。占用字节数越少，能够表示的数值范围就越小；反之，BIGINT 使用8字节，可以存储非常大的整数。对于大多数业务中的自增主键、用户ID、订单ID等，使用 INT 已经足够；而分布式系统生成的雪花ID等超大数值，则应选择 BIGINT 以避免越界。
| 类型名称 | 存储大小 | 有符号范围 | 无符号范围 | 适用场景 |
|---|---|---|---|---|
TINYINT | 1字节 | -128 ~ 127 | 0 ~ 255 | 状态值、标志位、小范围计数 |
SMALLINT | 2字节 | -32768 ~ 32767 | 0 ~ 65535 | 中等范围整数，如数量较少的分类编号 |
INT | 4字节 | -2147483648 ~ 2147483647 | 0 ~ 4294967295 | 用户ID、订单ID等常规整数 |
BIGINT | 8字节 | -9223372036854775808 ~ 9223372036854775807 | 0 ~ 18446744073709551615 | 分布式ID、超大规模计数 |
整数类型还可以使用 UNSIGNED 关键字定义为无符号类型，这样数值范围会向正数方向扩展，适合明确不会出现负数的列。例如年龄、数量、状态码等字段可以声明为 TINYINT UNSIGNED。此外，整数类型在定义时可以写成 INT(11) 这样的形式，但这里的显示宽度并不会改变字段的实际存储范围，它主要在使用 ZEROFILL 时影响数值左侧补零的显示效果。
小数类型分为浮点数和定点数。浮点数类型 FLOAT 和 DOUBLE 使用二进制近似表示数值，因此在进行运算时可能存在精度丢失。FLOAT 占用4字节，DOUBLE 占用8字节，后者能够保存更高的精度，但仍然不适用于需要精确计算的场景。金额、汇率、账户余额等数据应使用定点数 DECIMAL。DECIMAL 在存储时以字符串形式保存数字，因此可以做到精确表达，定义时需要同时指定总位数和小数位数，例如 DECIMAL(10,2) 表示总共10位数字，其中小数部分占2位。
字符串类型的存储特点
字符串类型用于保存文本和二进制内容，不同的字符串类型在存储方式上存在明显差异。对于长度基本固定的文本，可以选择定长字符串 CHAR；对于长度变化较大的文本，则更适合使用变长字符串 VARCHAR。CHAR(10) 无论实际保存多少个字符，都会占用10个字符的存储空间，因此适合手机号、身份证号、固定编号等长度固定的数据。而 VARCHAR(255) 只会占用实际字符长度加上1到2个字节的长度标识空间，能够减少存储浪费，适合用户名、地址、邮箱等长度不固定的数据。
在定义 VARCHAR 时，最大长度需要根据业务实际需要设置，而不是统一使用255。虽然 VARCHAR 本身按实际长度存储，但过大的最大长度可能会影响索引长度，尤其是当该列需要参与联合索引时。对于超过一定长度的文本，应该考虑使用 TEXT 类型。
长文本类型 TEXT 包含 TINYTEXT、TEXT、MEDIUMTEXT 和 LONGTEXT，各自的存储容量依次递增，适合保存文章正文、评论内容、产品描述等长文本数据。与 TEXT 对应的二进制类型是 BLOB，同样细分为 TINYBLOB、BLOB、MEDIUMBLOB 和 LONGBLOB，用于保存图片、文件等二进制内容。需要注意的是，TEXT 和 BLOB 通常不能设置默认值，并且在排序、临时表等场景下可能产生额外开销，因此不要滥用它们保存短文本。
枚举类型 ENUM 和集合类型 SET 适合保存一组预定义选项。ENUM 只能从中选择一个值，例如 ENUM('男','女','未知') 适合性别字段；SET 可以同时选择多个值，例如 SET('阅读','运动','音乐') 适合兴趣爱好等多选项数据。使用 ENUM 或 SET 可以让非法值在插入时被拒绝或转为空值，从而增强数据一致性，但如果业务选项频繁变化，维护这类字段会比较麻烦。
日期时间类型的选择
日期时间类型用于保存和时间相关的数据，不同格式之间的差异会直接影响业务逻辑和查询方式。最基础的 DATE 用于保存日期，格式为 YYYY-MM-DD，适合生日、入职日期等只需要年月日的数据。TIME 用于保存时间，格式为 HH:MM:SS，既可以表示一天中的某个时刻，也可以表示一段时长，适合保存营业时间、任务耗时等数据。YEAR 则只保存年份，格式为 YYYY，占用的空间很小，适合仅需要年份信息的场景。
在完整日期时间场景中，最常用的是 DATETIME 和 TIMESTAMP。DATETIME 保存日期和时间的组合，格式为 YYYY-MM-DD HH:MM:SS，不受时区转换影响，适合创建时间、支付时间等需要明确保存业务时间的字段。TIMESTAMP 虽然也保存日期时间，但它内部存储的是时间戳，并且会受到数据库时区设置的影响。当插入或更新行时，TIMESTAMP 可以自动设置为当前时间，适合需要自动维护的记录时间字段。
两者在范围上也有区别。DATETIME 支持的日期范围更广，能够表示从公元1000年到9999年之间的日期时间；而 TIMESTAMP 基于Unix时间戳，范围通常从1970年到2038年。因此，如果业务需要保存更久远的时间，或者对时区变化不敏感，应优先选择 DATETIME。如果希望数据库自动更新记录的修改时间，则可以使用 TIMESTAMP 并配合 ON UPDATE CURRENT_TIMESTAMP。
字段类型选择的核心原则
选择字段类型时，最优先的原则是在满足业务需要的前提下使用占用空间更小的类型。比如状态字段用 TINYINT 即可，不必使用 INT；能够用 DATE 保存的数据，就不要使用 DATETIME。对于整数字段，尽量避免使用字符串保存数字，这样不仅能减少存储空间，还能让数值比较和排序操作更高效。如果必须对数字进行精确计算，例如余额流水、财务报表，应使用 DECIMAL 而不是 FLOAT 或 DOUBLE。
在字符串类型的选择上，应优先考虑 VARCHAR 保存长度不固定的文本，长度固定的文本使用 CHAR。对于超过几千字符的文章、评论等内容，直接使用 TEXT。同时，尽量为字符串列设置合理的最大长度，不要一律定义为 VARCHAR(255)。对于日期时间字段，如果不需要自动更新，使用 DATETIME；需要自动记录更新时间时，可以使用 TIMESTAMP，但要注意它的范围限制。
字段类型的选择还要和索引设计结合起来。过长或过大的字段类型会导致索引体积膨胀，影响查询性能。对于频繁作为查询条件的列，应尽量使用较小的数值类型或前缀索引。对于布尔型或简单的状态值，可以使用 TINYINT 并建立普通索引。与此同时，应给必要的列明确指定是否允许 NULL，因为 NULL 值在索引和比较操作中会增加复杂度，通常建议重要业务字段使用 NOT NULL 并提供默认值。
建表语句示例分析
下面通过一个用户表的建表语句展示不同字段类型如何组合使用。该表包含用户ID、用户名、年龄、性别、账户余额、头像地址、个人简介、生日以及创建和更新时间。用户ID使用 INT UNSIGNED 并设置为自增主键，这样既能保证唯一性，又能避免负数。年龄使用 TINYINT UNSIGNED，足够覆盖正常年龄范围且占用空间较小。性别使用 ENUM 限制为固定选项，避免插入非法值。
账户余额使用 DECIMAL(10,2) 保存，避免浮点数计算导致的金额误差。头像地址使用 VARCHAR(255) 保存URL字符串，个人简介使用 TEXT 保存长文本。生日字段使用 DATE，创建时间使用 DATETIME，更新时间使用 TIMESTAMP 并声明自动更新，这样可以减少应用层维护时间字段的成本。
-- 创建用户信息表，演示常用字段类型的组合使用
CREATE TABLE user (
id INT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '用户ID',
username VARCHAR(50) NOT NULL COMMENT '用户名',
age TINYINT UNSIGNED NOT NULL DEFAULT 0 COMMENT '年龄',
gender ENUM('男','女','未知') DEFAULT '未知' COMMENT '性别',
balance DECIMAL(10,2) NOT NULL DEFAULT 0.00 COMMENT '账户余额',
avatar_url VARCHAR(255) DEFAULT '' COMMENT '头像地址',
intro TEXT COMMENT '个人简介',
birthday DATE DEFAULT NULL COMMENT '生日',
created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
updated_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
PRIMARY KEY (id),
KEY idx_username (username)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户信息表';
总地来说，字段类型的选择不是孤立的技术细节，而是表结构设计的基础。只有结合数据特征、查询方式和增长预期来确定每一列的类型，才能在存储成本、性能和数据正确性之间取得平衡。实际建表时，可以从最严格的类型开始评估，再根据真实数据分布进行微调，这样能避免后续因为类型选择不当而进行高成本的表结构变更。