MySQL 数字类型字段设计指南：从底层语义到大型系统实践

数据库世界有一种错觉： 数字只是数字。

可一旦系统规模变大、数据年限拉长，你会发现—— 字段设计其实是在给“未来十年的业务”写契约。

这篇文章不是语法教学，而是一份偏架构视角的数字字段设计手册，覆盖：

• 类型选择策略
• 默认值哲学
• NOT NULL 的真实含义
• 状态字段设计
• 金额与精度
• 性能与索引
• 避坑指南

目标只有一个：

让你的表结构在五年后看起来依然像“设计过的”，而不是“拼出来的”。

一、理解本质：字段不是存数据，而是表达业务

很多开发把字段当作“容器”，其实它更像：

数据库层的业务声明语言。

例如：

status TINYINT NOT NULL DEFAULT 1

这句话在表达：

• 状态必须存在
• 默认是“安全状态”
• 不允许未知值

字段设计 = 业务规则前移。

系统越大，这一点越重要。

二、MySQL 数字类型如何选择（不是背表，而是理解成本）

先给一个工程化结论：

永远选择“够用的最小类型”。

原因非常现实：

• 更小的类型 → 更小的索引
• 更小的索引 → 更少的 IO
• 更少的 IO → 更稳定的延迟

这是数据库的物理规律。

推荐选择策略

✅ TINYINT（1字节）

适合：

• 状态
• 枚举
• 布尔
• 开关

例如：

is_deleted TINYINT(1) NOT NULL DEFAULT 0

极高性价比字段。

但注意：

TINYINT(1) 不是布尔类型。 括号里的 1 只是显示宽度（MySQL 8 已基本忽略）。

✅ INT（4字节）

默认首选类型。

适合：

• 用户ID
• 订单ID
• 计数
• 常规业务数值

如果你拿不准，用 INT 通常不会错。

✅ BIGINT（8字节）

不要滥用，但也不要恐惧。

适用于：

• 分布式ID（雪花算法等）
• 超大表主键
• 日志系统

一个常见误区：

“先用 INT，不够再升级。”

现实是：

主键升级几乎等于重建整表。

如果预计会破 20 亿，直接 BIGINT。

⚠️ DECIMAL —— 金额唯一正确答案

永远记住：

涉及钱，禁止使用 FLOAT / DOUBLE。

原因不是“可能不精确”。

而是：

一定会出现误差。

正确写法：

amount DECIMAL(10,2) NOT NULL

解释：

• 10：总位数
• 2：小数位

最大值：99999999.99

设计秘诀：

按“最大可能金额 × 10倍”预留。

避免未来改表。

三、NOT NULL 的真实意义（90%的人理解错）

NOT NULL 不只是“不能为空”。

它在表达：

这个字段在业务上“必须存在”。

所以关键问题不是：

能不能 NULL？

而是：

业务是否允许“未知”？

推荐判断模型

问自己三件事：

1️⃣ 这个值是否一定存在？ 2️⃣ 是否允许“未确定”？ 3️⃣ NULL 是否具有业务意义？

如果 NULL = “未知 / 待计算 / 未同步”

👉 允许 NULL 往往更高级。

例如：

paid_at INT NULL

NULL 表示：

“还没付款”

比写 0 高级得多。

因为：

• 0 是假数据
• NULL 是语义数据

四、DEFAULT 的哲学：不是偷懒，是宣言

DEFAULT 在数据库中的真实作用是：

定义“沉默输入”的含义。

当应用没传值时，数据库替你做决定。

所以必须问：

这个决定安全吗？

DEFAULT 的黄金法则

✅ 给“安全起点”

例如：

status TINYINT NOT NULL DEFAULT 1

前提：

1 必须是最保守状态。

例如：

• 未激活
• 普通用户
• 草稿

而不是：

• 已支付
• 已审核
• VIP

❌ 禁止 DEFAULT 0（当 0 无意义）

最常见的数据污染源。

因为未来没人知道：

0 = 默认？ 0 = bug？ 0 = 历史脏数据？

如果 0 没业务含义：

👉 不要用。

✅ 必须显式设置的字段 —— 不给 DEFAULT

例如：

• 支付金额
• 用户ID
• 订单类型

让应用强制传值。

这是一种：

架构层面的防御设计。

五、状态字段设计：避免灾难的关键

强烈建议：

把状态字段当作“微型状态机”。

示例：

status TINYINT NOT NULL DEFAULT 0
COMMENT '0=草稿,1=待审核,2=已发布,3=已下线'

核心原则：

✅ 状态必须连续

不要：

1, 3, 7, 99

这是维护噩梦。

✅ 永远使用“白名单查询”

正确：

WHERE status = 2

危险：

WHERE status != 0

后者本质是在赌：

未来不会新增状态。

而现实一定会新增。

六、无符号 UNSIGNED：是否值得用？

很多人纠结：

要不要 UNSIGNED？

结论：

只在“绝不可能为负”的字段使用。

例如：

• 库存
• 次数
• 年龄

好处：

• 上限翻倍

但注意：

UNSIGNED 会改变比较规则。

跨系统时要谨慎。

七、性能视角：数字类型影响的不只是空间

数据库性能核心在：

索引大小。

举个直觉案例：

• BIGINT 索引 ≈ INT 的两倍
• 亿级数据 → 差距巨大

所以：

不要因为“看起来高级”就用 BIGINT。

数据库不吃审美，只吃 IO。

八、最常见的设计错误（建议自查）

❌ 用 FLOAT 存金额

后果：对账地狱。

❌ 所有字段 NOT NULL + DEFAULT 0

后果：数据语义消失。

❌ 状态用 VARCHAR

后果：索引效率暴跌。

❌ 过早 BIGINT

后果：索引臃肿。

❌ 把数字当字符串

例如手机号。

记住：

可计算 → 数字 不参与计算 → 字符串

手机号需要：

• 前导0
• 国家码
• 格式化

所以应为字符串。

九、一套可直接落地的字段设计原则

如果只能记住几条，请记住这些：

选择最小够用类型。 金额永远 DECIMAL。 DEFAULT 是业务声明。 NULL 可以是高级语义。 状态字段就是状态机。 只用白名单查询。

当你开始用“业务语言”设计字段时：

你的数据库就进入了架构级别。

结语

优秀的表结构有一个共同特征：

新人看到字段，就能理解业务。

而不是靠读代码猜。

字段设计，本质是：

把混乱挡在数据库之外。

当系统增长十倍时，你会感谢今天这个克制而理性的自己。