MySQL数据类型与表约束实战：字段选型与建表规范全解析

你有没有遇到过这种情况：接手一个跑了半年的系统，发现“用户年龄”这一列有的人存了整数，有的人存了“25岁”，还有人存了 NULL；某个订单金额明明很接近，算起总账却差出几分钱；一个理论上最多几千行的配置表，查询慢得像在爬山。这些毛病十有八九不是业务代码写错了，而是建表时数据类型和表约束没规划好。MySQL 作为一种关系型数据库，它的能力边界很大程度从字段类型和约束就开始决定了，但我见过太多项目把类型当摆设、把约束当注释，最后数据质量崩塌、改造成本翻倍。

这篇文章我不想写成一个 API 手册式的翻页文档，而是想用做项目时会真正遇到的角度，把 MySQL 的数值类型、字符串类型、日期时间类型，再加上主键、外键、唯一约束这些“表约束”逐个拆开讲。适合刚学完基础 SQL、准备自己设计表结构的人，也适合已经写了一段时间业务、却总被线上数据问题折磨的开发。你会看到很多我在真实业务里的取舍，包括那些踩过之后才明白的“为什么”。

1. 为什么说数据类型选错比业务逻辑写错更麻烦

1.1 数据类型的本质不是“字段格式”，而是底层存储协议

不少初学者会把字段类型理解成一种“格式”，觉得 varchar(20) 就是“最多放 20 个字的文本格式”，int 就是“数字格式”。这个理解方向没有错，但没有触及关键。

在 MySQL 里，一个表最终会落到磁盘的存储引擎上。以最常用的 InnoDB 为例，数据是按行记录方式存储，每个字段是按类型编码写入页文件的。也就是说，类型决定的不只是“能不能填”，而是“这一列在磁盘上占几个字节、按什么规则比较大小、建索引时如何排序、查询引擎能不能直接走索引”。我把类型比作物流仓库里的货位规划：货位设计得合理，叉车来回次数少，仓库吞吐量高；货位设计得随意，货物越多，场内越乱，出库效率越低。

MySQL 官方文档里常见类型可以粗略分几组：整数类型（TINYINT、SMALLINT、MEDIUMINT、INT、BIGINT）、浮点与定点数类型（FLOAT、DOUBLE、DECIMAL）、字符串类型（CHAR、VARCHAR、TEXT 系列）、二进制类型（BINARY、VARBINARY、BLOB 系列）、日期时间类型（DATE、TIME、DATETIME、TIMESTAMP、YEAR）、以及 JSON、ENUM、SET 这类特殊类型。这些类型在存储空间、取值范围、比较规则上完全不同。

值得强调的一点是：一旦业务上线，数据源源不断写入，再想修改字段类型通常意味着大表 DDL，甚至要重建表。MySQL 8.0 虽支持了 INPLACE 的部分改列操作，但依然存在锁表窗口和回滚成本。所以建表时花几分钟想清楚每一列到底是什么，远比后面加班补数据要划算。

1.2 字段设计混乱带来的连锁反应

我把实际项目中因为类型选错导致的麻烦列一个典型的链路，你感受一下：

• 手机号字段如果用了 BIGINT，那么以 0 开头的手机号会被截断；
• 如果手机号字段用了 varchar(11)，却有不少人存了 NULL，那查询“WHERE phone IS NULL”时，业务代码常会忘记单独判断；
• 身份标识字段如果不区分状态类型，后续统计时不得不用一堆模糊 LIKE 去匹配；
• 金额字段如果用 FLOAT，则累加运算会出现精度漂移，导致对账不平；
• 一个本该用 TINYINT 表示的状态位，却设计成 VARCHAR(255)，索引体积膨胀好几倍，扫描行数多出几个量级。

这些问题的可怕之处在于，它们大多不会在建表当天爆发，而是等到数据量上来、报表开始统计、业务系统开始对接时，才集中暴露。那时你已经无法通过“修改应用代码”解决，只能做数据订正或拆表迁移。做过一次你就会明白，代价小则几个小时，大则跨周。

所以我把类型与约束的设计称作“数据库的架构决策”，它不是写 CRUD 时顺手加个字段那么简单的事。

1.3 一张表看清“错误设计”与“正确设计”的差距

下面是一个“用户账号表”的简化例子，左边是我经常在接手项目里看到的反面设计，右边是更合理的方案：

上表对应的每一个改动，都意味着业务代码中要同步处理。字段类型不是文档里写一次就结束的“注释”，它是所有 SQL 语句、ORM 实体、接口返回结构的数据地基。地基打偏了，楼层越高风险越大。

2. 数值类型实战：从 TINYINT 到 DECIMAL 的取舍逻辑

2.1 整数类型：先把 int(5) 这个误区解决掉

很多人在建表时写过这样的语句：

sql复制CREATE TABLE user (
    id INT(5) NOT NULL AUTO_INCREMENT,
    ...
);

这里最常见的误解是：INT(5) 表示“最多只能存 5 位数”。这个说法是错的。

INT 类型在 MySQL 中固定占用 4 个字节，无论括号里写 5 还是 11，它能存储的范围都是 -2147483648 到 2147483647（无符号为 0 到 4294967295）。括号里的数字是“显示宽度”，它只在设置了 ZEROFILL 属性时会影响展示方式，例如 INT(5) ZEROFILL 会把 42 显示为 00042，而不会限制你存入 123456。在 MySQL 8.0 里，显示宽度已被标记为废弃，将来可能会移除。所以在实际项目里我建议你干脆不写这个括号参数，别给自己和别人留误解空间。

各整数类型真正的差异在于存储范围和字节数：

设计上的建议是：能用 TINYINT 表示的状态就别用 INT，能用 INT 表示的主键就别用 BIGINT。这里的收益不是“省几个字节”那么简单，而是索引页里能容纳更多索引项，InnoDB 的 B+ 树扫描效率会更高。一个一百万行的表，如果主键从 INT 改成 BIGINT，普通索引的叶子节点存储主键列所占空间也会变大，最终影响的是整棵索引树的扇出。

2.2 小数到底该用 FLOAT、DOUBLE 还是 DECIMAL

这大概是电商、财务、统计系统里最容易被坑的点。FLOAT 和 DOUBLE 是浮点数，它们在计算机内部使用二进制科学计数法表示，因此很多十进制小数无法被精确表示。举例来说，0.1 用二进制浮点数表示时是一个无限循环小数，存进去再算出来，尾数就可能变成了 0.10000000000000000555。单个数字看不出问题，但累加多了，误差就会累积。

我在一个交易对账项目里踩过一次：订单金额用 DOUBLE 存储，单笔金额是 0.1 元，一天几千笔订单累加，最后对账差出整整 1.17 元。这笔账不是业务 bug，是存储类型误差。从那之后，凡是涉及“钱”的字段，我统一使用 DECIMAL。

sql复制-- 金额字段规范做法
price DECIMAL(10,2) NOT NULL DEFAULT 0.00,

DECIMAL 是 MySQL 的定点数类型，它按十进制字符串进行存储，不会出现二进制浮点的精度问题。DECIMAL(10,2) 表示总位数 10 位，小数部分 2 位，整数部分最多 8 位。对绝大多数业务来说，总金额到亿级已经足够；如果做批发或金融级业务，可以按需使用 DECIMAL(18,4) 或更高的精度。

2.3 自增主键选型的判断

MySQL 建表时最常见的自增主键写法是 id INT NOT NULL AUTO_INCREMENT。但在分库分表、数据量预估很大的场景下，INT 上限是 42 亿，看着很多，实际上当一张表拆到多个实例后，每个实例分配的自增区间可能很快耗尽。我自己遇到过一张订单流水表，因为历史数据较多，某个分片自增主键已经超过 20 亿，最后不得不停机改列类型为 BIGINT。所以比较新的表我都会直接考虑 BIGINT，尤其对日志、流水、消息场景。

还有一类表的主键不适合自增：对外暴露的 ID 不想让外界通过数字增量猜测业务规模；或者需要在多个服务端生成不重复 ID。这时常见的替代方案是 64 位雪花 ID 或 UUID 的二进制优化版本。雪花 ID 通常是一个 BIGINT 类型，本身适合作为主键。UUID 如果存成 CHAR(32) 是反面教材，更好的做法是存成 BINARY(16) 或用 MySQL 8.0 提供的 UUID_TO_BIN 函数转换。不过注意：随机主键在 InnoDB 中可能导致页分裂和写入性能下降，如果是小项目没那么明显，但高并发写入场景需要提前考虑缓冲。

sql复制-- 生产环境推荐的用户表主键写法
CREATE TABLE `user` (
    `id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '主键ID',
    ...
    PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

3. 字符串和日期类型：那些让人“改表”的存储细节

3.1 CHAR、VARCHAR、TEXT 三兄弟怎么选

字符串是业务表里出现频率最高的类型，也是滥用程度最高的类型。很多开发习惯所有短文本一律 VARCHAR(255)，所有说明一律 TEXT，看似省心，实则给数据库埋了不少雷。

CHAR 是定长字符串，比如 CHAR(10) 会固定占用 10 个字符的空间，不足部分以空格补齐。它的查询效率高，几乎不会产生行迁移碎片，适合长度波动很小的字段，比如手机号、身份证号、固定状态码和 MD5 哈希值。VARCHAR 是变长字符串，最多能存 65535 字节，但需要额外 1 到 2 个字节存储实际长度。它的存储更省空间，但频繁更新导致长度变化时，InnoDB 可能出现页内分裂，更新成本略高于 CHAR。

MySQL 中的 VARCHAR(M) 中 M 的单位是“字符”，不是字节。这个细节很容易被忽略，尤其在使用 utf8mb4 字符集时，一个字符最多占 4 字节。这意味着 VARCHAR(255) 在 utf8mb4 下最多可能占用 255*4 = 1020 字节。而 InnoDB 单列索引有一个最大长度限制：当使用 DYNAMIC 行格式时，索引键前缀最多 3072 字节；对于老版本的 767 字节限制，则 VARCHAR(255) 的 utf8mb4 列做索引会直接报错。这就是网上总能看到“VARCHAR 加索引失败”的原因之一。

TEXT 系列（TINYTEXT、TEXT、MEDIUMTEXT、LONGTEXT）有更大的容量，但它们有一个让新手头疼的问题：TEXT 列不能设置默认值（在 MySQL 8.0 之前更是如此），并且对 TEXT 列建立索引时必须指定前缀长度，不能像普通短字符串一样直接整列索引。如果你需要保存文章正文、JSON 大字段、日志原文，TEXT 系列是合理的；但如果只是存状态描述这种很短的文本，就不要用 TEXT。

3.2 字符集与排序规则的连锁影响

字符集建议统一 utf8mb4，排序规则通常使用 utf8mb4_0900_ai_ci（MySQL 8.0）或 utf8mb4_general_ci（MySQL 5.7 常见）。有人问 utf8 和 utf8mb4 有什么区别？在 MySQL 里，utf8 其实是 utf8mb3 的别名，它最多用 3 个字节表示一个字符，存不了 emoji 和部分生僻汉字。如果表用了旧 utf8，而程序又写入了一个 😀 表情，就会变成一串问号或者直接报错。

更隐蔽的问题是排序规则影响查询相等性判断。utf8mb4_general_ci 是大小写不敏感的比较，意味着 条件 WHERE name = 'abc' 能匹配到名称为 “ABC” 的行。如果业务需要严格区分大小写，则要考虑使用 utf8mb4_bin 排序规则。这个特性放在表约束阶段想清楚，总比到线上后一条 SQL 返回了多余记录再排查要舒服得多。

3.3 DATETIME 与 TIMESTAMP：时间字段的经典抉择

时间日期字段是另一个容易踩坑的重灾区。初学者常会直接拿 VARCHAR 存时间，比如“2024-01-15 10:30:00”，看起来直观，但完全破坏了 SQL 的日期比较函数和索引范围扫描能力。正确做法是用原生日期类型。

DATETIME 与 TIMESTAMP 的核心差异可以整理成一张表：

这里有三个实践建议。第一，新项目的时间记录大多使用 DATETIME，规避 2038 年问题。第二，需要记录“插入时间”和“最后更新时间”时，可以直接用 DEFAULT CURRENT_TIMESTAMP 和 ON UPDATE CURRENT_TIMESTAMP，让数据库维护时间，不要依赖业务代码。第三，如果系统要面向多时区用户，更推荐 TIMESTAMP 或统一存储 UTC 时间后再转当地时间；如果业务就是本地单时区，DATETIME 反而直观。

sql复制CREATE TABLE `order` (
    `id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
    `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
    `updated_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
    PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

3.4 别忘了一批“特殊兄弟”：ENUM、SET、JSON、BOOLEAN

把 BOOLEAN 单独放在一起，是因为 MySQL 并没有独立的 BOOLEAN 类型，它实际上是 TINYINT(1) 的别名，允许存 0、1 以及非 0 值。如果你硬插入 2，它也会被当作真值。很多人以为 BOOLEAN 会自动做约束，其实没有。所以真正要严格限制只能 0 或 1，还得靠 CHECK 或业务代码保证。

ENUM 本质上是枚举类型，适合状态字段。它在底层以整数存储，取值只能是列表内元素。优点是节省空间，代码可读性也不错。但我在项目中使用比较谨慎，原因是修改枚举列表时必须通过 ALTER TABLE 修改表结构，如果业务扩展频繁，批量刷数据会带来额外成本。同理，SET 类型适合多个选项可以并存的场景，但它也存在扩展不够灵活的缺点。

JSON 类型是 MySQL 5.7 引入、8.0 重点增强的字段。它适合存储结构不太固定、需要灵活查询的文档数据。要注意两点：第一，JSON 列不能有默认值（除非表达式默认值从 8.0.13 起支持），也不适合频繁更新的场景，因为每次更新会重写整个 JSON 文档；第二，虽然 8.0 支持对 JSON 字段的部分属性建生成列索引，但整体查询效率不如普通关系模型。业务里如果能拆成常规列，就不要偷懒全部塞进 JSON。JSON 是“最后的手段”，不是“万能口袋”。

4. 表约束体系：让数据库成为最后一个守门员

4.1 约束类型盘点，以及它们的触发时机

如果把数据类型比作字段的“天花板和地板”，那么约束就是字段的“门禁规则”。MySQL 常用的表约束包括：

• NOT NULL：禁止该列写入 NULL；
• DEFAULT：提供默认值，避免业务漏传导致 NULL 进入；
• UNIQUE：保证列或列组合的值唯一；
• PRIMARY KEY：唯一标识一行，相当于 NOT NULL + UNIQUE 的加强版；
• CHECK：从 MySQL 8.0.16 起才被真正强制执行；
• FOREIGN KEY：维护子表与父表之间的引用完整性。

此外还有 AUTO_INCREMENT 属性，它常和主键一起出现；以及创建索引这个逻辑上的约束手段。它们之间的核心区别是：约束守护的是数据“合法且关系正确”，索引则是加速查询但不一定保证数据完整性。

NOT NULL 和 DEFAULT 要组合起来看。比如“状态”字段，虽然允许 NULL 有时可以用“NULL 表示未知”来暗示业务，但在实际查询中，NULL 会让统计函数（COUNT、SUM）的语义变得很别扭。COUNT(column) 不会统计 NULL 行，COUNT(*) 才统计所有行。很多报表数据对不上，就是因为某个字段 NULL 值太多，开发误用 COUNT 导致统计口径不一致。所以在非必要的业务列上，我都倾向加上 NOT NULL DEFAULT 一个合理值，把状态收敛成有限集合。

4.2 主键设计：自然主键还是代理主键？

主键是整个约束体系的核心。MySQL 的 InnoDB 是聚簇索引组织表，数据行按主键物理排序存放。这意味着主键的选择不仅影响唯一性，还影响写入和查询的物理布局。比较推荐的是使用自增 ID 或雪花 ID 这类单调递增的代理主键作为主键。为什么？因为它能尽量让新行追加到聚簇索引的尾部，减少页分裂和随机 IO。

而自然主键，比如以身份证号作为用户主键，很容易触碰几个问题：身份证号属于敏感个人数据，不应在数据库里频繁作为公共标识；证件类型如果未来扩展到护照、港澳台通行证，主键字段就得推翻重建；甚至身份证号本身因为号码格式更新（如长度变更）都会成为灾难。所以我的原则是：任何一张业务表，都搞一个无业务含义的 id 作为代理主键，然后再把真正的业务唯一标识，如手机号、身份证号、订单号，另外建唯一约束。这样既保证了物理存储稳定，又保证了业务数据不重复。

4.3 UNIQUE 约束与 NULL 的关系

UNIQUE 约束在 MySQL 中有一个“历史特性”：它允许多个 NULL 值存在。数学上“NULL = NULL”的结果是“UNKNOWN”，所以唯一索引不会把两条 NULL 记录判定为冲突。举例来说，一个“企业员工邮箱”列为 UNIQUE，但公司允许部分员工没有邮箱，那么你插入两条 mail 都是 NULL 的记录，数据库并不会报错。这在某些业务场景下是符合预期的，但如果你希望“最多只有一个用户没有邮箱”，光靠 UNIQUE 约束做不到。这时候解法通常是再造一个“标记列”，保证有标记列的查询条件下唯一，或者在应用层加锁判断，甚至使用生成列辅助。这个问题比较刁钻，面试题里也常爱问，但实际业务里确实会踩。

4.4 外键和 CHECK：用还是不用？

外键约束是关系数据库完整的标志特性。但互联网大厂里普遍不推荐在业务表上大量使用外键，更常见的方式由应用层服务去保证引用关系。原因有三个：第一，外键在写入、更新、删除时都要做一致性检查，会增加性能开销；第二，在分库分表后，外键根本无法跨越数据库实例工作；第三，很多高并发系统采用最终一致性设计，并不需要数据库强一致性瞬时报错。但这不代表外键一无是处。对于后台管理系统、内部数据系统、数据一致性要求极高的核心模型，外键仍然是一种廉价的防御手段，能防止粗心的开发写坏关联数据。

CHECK 约束同样经历了一段尴尬期。MySQL 5.7 及其以前版本虽然支持在语法中写 CHECK，但解析后直接忽略，导致很多人以为自己在约束字段，实际形同虚设。从 MySQL 8.0.16 开始，CHECK 才真正被强制执行。所以如果你还在用 5.7，并在表里写了 CHECK (gender IN ('M','F'))，别指望它保护数据。如果升级到 8.0，建议把这类能表达的规则直接写进 DDL，这样应用代码即使漏判，数据库也能兜底。

sql复制CREATE TABLE `employee` (
    `id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '主键',
    `gender` TINYINT NOT NULL DEFAULT 0 COMMENT '性别：0未知，1男，2女',
    `salary` DECIMAL(12,2) NOT NULL DEFAULT 0.00 COMMENT '薪资',
    PRIMARY KEY (`id`),
    CONSTRAINT `chk_gender` CHECK (`gender` IN (0, 1, 2)),
    CONSTRAINT `chk_salary` CHECK (`salary` >= 0)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='员工表';

看到这里你应该明白，约束并不只是写在文档里的业务规则，它应该是数据库本身要执行的逻辑。多一道数据库守门，数据质量就多一分保障。

5. 从 0 到 1：设计一套订单相关表结构的完整实战

5.1 业务需求梳理

为了把上面的内容落到实际，我这里设计一个简化但完整的“用户下单”场景。需求大致如下：

• 用户注册时记录手机号、昵称、注册时间；
• 用户可以有多种状态：待激活、正常、禁用；
• 用户下单时生成订单，记录下单用户、订单金额、支付状态、收货地址快照；
• 一个订单可能包含多个商品，所以要抽出订单明细表；
• 每个商品有自己的分类、单价和库存；
• 所有金额都要精确到分，所有状态都需要明确不可为 NULL；
• 订单号需要保持业务唯一。

5.2 字段类型和约束的设计过程

用户的手机号字段，我建议用 VARCHAR(20) 而不是 BIGINT。虽然中国大陆手机号是 11 位数字，但国际上有些号码带加号或短横线，甚至未来支持座机格式，所以 VARCHAR 对这种“看起来是数字、实际是字面量”的字段更安全。唯一约束可以在手机号上设置，但要注意 NULL 的语义：如果一个账号还没有绑定手机号，不应该阻止他人填入 NULL。

用户状态字段，我建议用 TINYINT NOT NULL DEFAULT 0，配合 CHECK 限制。不用 VARCHAR 的原因是：状态在代码里会被大量用于过滤和统计，用整数效率更高，排序也更可控；扩展性上新增一个状态不需要修改数据库表，只要约定数字编码即可。

订单金额字段统一使用 DECIMAL(12,2)，应对绝大多数交易场景；如果公司要求更精确的分账逻辑，也可以保留 4 位或 6 位小数。库存数量用整数类型，因为它本质上是离散量，不存在小数。

商品“分类”字段，如果分类数量很少且固定，可以用 TINYINT；分类体系复杂，则应拆成单独的分类表，通过外键或唯一索引关联。这里我拆分出一个分类表，并在商品表上存 category_id BIGINT，并设置普通索引。

订单号业务上必须唯一，所以增加 UNIQUE KEY。但不建议把它设为主键，否则聚簇索引的随机性会影响写入性能。主键仍使用自增 BIGINT。订单状态、支付方式、收货地址都可以用整数枚举或单独字典表来维护。

5.3 完整的 DDL 示例

sql复制CREATE TABLE `user` (
    `id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '用户ID',
    `phone` VARCHAR(20) NOT NULL COMMENT '手机号',
    `nickname` VARCHAR(50) NOT NULL DEFAULT '' COMMENT '昵称',
    `status` TINYINT NOT NULL DEFAULT 0 COMMENT '状态：0待激活，1正常，2禁用',
    `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '注册时间',
    `updated_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
    PRIMARY KEY (`id`),
    UNIQUE KEY `uk_phone` (`phone`),
    CONSTRAINT `chk_user_status` CHECK (`status` IN (0, 1, 2))
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表';

CREATE TABLE `category` (
    `id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '分类ID',
    `name` VARCHAR(50) NOT NULL COMMENT '分类名',
    `parent_id` BIGINT UNSIGNED NOT NULL DEFAULT 0 COMMENT '父分类ID，0表示根分类',
    PRIMARY KEY (`id`),
    KEY `idx_parent_id` (`parent_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='商品分类表';

CREATE TABLE `product` (
    `id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '商品ID',
    `category_id` BIGINT UNSIGNED NOT NULL COMMENT '分类ID',
    `name` VARCHAR(120) NOT NULL COMMENT '商品名称',
    `price` DECIMAL(12,2) NOT NULL DEFAULT 0.00 COMMENT '单价',
    `stock` INT UNSIGNED NOT NULL DEFAULT 0 COMMENT '库存',
    `status` TINYINT NOT NULL DEFAULT 1 COMMENT '状态：0下架，1上架',
    `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
    PRIMARY KEY (`id`),
    KEY `idx_category` (`category_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='商品表';

CREATE TABLE `order` (
    `id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '订单ID',
    `order_no` VARCHAR(32) NOT NULL COMMENT '业务订单号',
    `user_id` BIGINT UNSIGNED NOT NULL COMMENT '用户ID',
    `total_amount` DECIMAL(12,2) NOT NULL DEFAULT 0.00 COMMENT '总金额',
    `pay_status` TINYINT NOT NULL DEFAULT 0 COMMENT '支付状态：0待支付，1已支付，2已退款',
    `consignee_name` VARCHAR(50) NOT NULL DEFAULT '' COMMENT '收货人',
    `consignee_phone` VARCHAR(20) NOT NULL DEFAULT '' COMMENT '收货电话',
    `shipping_address` VARCHAR(255) NOT NULL DEFAULT '' COMMENT '收货地址快照',
    `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
    `paid_at` DATETIME NULL DEFAULT NULL COMMENT '支付时间',
    PRIMARY KEY (`id`),
    UNIQUE KEY `uk_order_no` (`order_no`),
    KEY `idx_user_id` (`user_id`),
    KEY `idx_created_at` (`created_at`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单主表';

CREATE TABLE `order_item` (
    `id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '明细ID',
    `order_id` BIGINT UNSIGNED NOT NULL COMMENT '订单ID',
    `product_id` BIGINT UNSIGNED NOT NULL COMMENT '商品ID',
    `product_name` VARCHAR(120) NOT NULL COMMENT '商品名快照',
    `price` DECIMAL(12,2) NOT NULL DEFAULT 0.00 COMMENT '下单时单价',
    `quantity` INT UNSIGNED NOT NULL DEFAULT 1 COMMENT '数量',
    `subtotal` DECIMAL(12,2) NOT NULL DEFAULT 0.00 COMMENT '小计金额',
    PRIMARY KEY (`id`),
    KEY `idx_order_id` (`order_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单明细表';

这段 DDL 里有几个值得留意的设计：商品名称和收货地址这类业务快照字段，没有通过 JOIN 去“现查”，这是订单系统的常见需求。历史订单不能因为商品后来改名、下架而消失，所以冗余快照字段反而保证了数据稳定性。这种冗余看似违背了三范式，却是实际业务里非常常见的反范式设计。金额字段都用了 DECIMAL，并默认 0.00；状态字段用 TINYINT 并配合 CHECK；订单号加唯一索引，主键保持自增。所有这些设计，正是数据类型和表约束这两个主题的组合应用。

6. 我踩过的坑，以及新建表时的自查清单

6.1 几个高频翻车实录

先说一个很典型的翻车点：唯一约束加在可空列上。我之前维护过一个“邀请码绑定表”，设计时给邀请码列加了 UNIQUE，但业务允许用户未绑定时为 NULL。结果上线一段时间后发现，多个用户都可以处于“未绑定”状态。这是不是 bug？从唯一索引的角度来看不是，因为 MySQL 允许多个 NULL；但从业务视角看，可能会产生“一个邀请码被多次领取”的误解。后来我把该列改成 NOT NULL DEFAULT ''，并给空串单独规定业务语义，才避免了混乱。这也提醒我：约束的语义和业务的语义，一定要在设计文档里对齐。

第二个高频坑是“时间字段索引不生效”。部分开发喜欢把查询条件写成 WHERE DATE(created_at) = '2024-01-01'，这样即使 created_at 上有索引也无法使用，因为对列做了函数操作，索引失效。正确方式是 WHERE created_at >= '2024-01-01' AND created_at < '2024-01-02'。这也是日期时间类型必须设计成原生类型的原因：一旦存 VARCHAR，函数转换更是家常便饭，索引基本形同虚设。

第三个高频坑有关大表 DDL。我在一个数据量超过一千万行的表上执行过一次 ALTER TABLE ... MODIFY COLUMN，虽然没有长时间锁死，但依然导致主从延迟飙升到几分钟，最后只能深夜操作并限流。所以在数据量大的表上，类型选择和约束设计务必一次到位，不要抱着“先上线，后面再改”的想法。

6.2 我的建表自查清单

现在我每建一张表都会做一次快速的“类型与约束体检”。这份清单写给你参考：

• 数值型字段是否遵循“能小则小”的原则？像状态位优先 TINYINT，而不是 INT。
• 是否存在 VARCHAR 存数字的偷懒行为？手机号、身份证号这类“需要原样保存且不做数值计算”的字段可用 VARCHAR，但不要用 VARCHAR 存年龄、金额并参与计算。
• 所有金额字段是否使用 DECIMAL？有没有残留 FLOAT 或 DOUBLE？
• 是否设置了合理的 NOT NULL 和 DEFAULT？业务字段尽量不要有悬空 NULL。
• 主键是否单调递增？是否需要 BIGINT？
• 业务唯一键是否用 UNIQUE KEY 显式声明？有没有数据库层本可以拦住的重复数据？
• 时间字段是否采用 DATE/DATETIME/TIMESTAMP？有没有用 VARCHAR 存时间？
• 字符集和排序规则是否统一？索引列的长度是否在限制内？
• 外键和 CHECK 是否按实际版本真正生效？如果仍是 MySQL 5.7，别把数据完整性完全交给数据库。

这套清单看起来琐碎，但它相当于给数据库表上了一道保险。我自己每次上完线后，还会跑几条 SQL 去检查实际插入的数据分布，例如看看某列是否有预期之外的空值、枚举值是否漂移。下面这个查询可以快速找出某张表的异常状态记录：

sql复制SELECT status, COUNT(*) AS cnt
FROM user
GROUP BY status
ORDER BY cnt DESC;

如果查询结果出现了设计文档中没有的编码，基本可以确定业务代码在某个分支写入非法值了。这时候再回头修逻辑，比起等到报表出问题再“考古”，要轻松得多。

数据库的建表能力，确实是在一行又一行的 DDL 中练出来的。类型和约束这些概念看似基础，实际上最考验一个开发者对存储、查询、业务一致性的综合理解。希望这篇内容能让你在下次建表时多想一层：每一个字段背后，都有一个数据的生命周期需要被呵护。