MySQL中除了int整数类型整形还有哪些类型int类型占用

面试题/真实面试/2026/MySQL中除了int整数类型整形还有哪些类型int类型占用.md

MySQL中除了int整数类型整形还有哪些类型int类型占用

首次来源：北京万联易达 2026-01-23 一面

原题

MySQL 中，除了 int（整数）类型，整形还有哪些类型？int 类型占用多少字节？

完整讲解（权威版）

最后更新：2026-10-29 · 基于第 1 次作答

L1 · 30 秒速记

结论：MySQL 整数类型按字节数递增为 TINYINT(1)/SMALLINT(2)/MEDIUMINT(3)/INT(4)/BIGINT(8)，int 占 4 字节。关键词：TINYINT · SMALLINT · MEDIUMINT · BIGINT · unsigned 边界：占用字节固定不变，但可显示宽度与存储字节是两回事，别把 INT(11) 当成存储上限。

L2 · 核心讲解

核心考点定位：面试官想确认你是否把「整数类型字节数」这个最底层的内存/存储事实记准，并且能区分「可显示宽度」（MySQL 8 已废弃）与「实际存储字节」——很多人把 INT(11) 误解为只能存 11 位。

机制链（≥3 环）：

列类型决定存储 → 每行该列按固定字节分配：为什么 InnoDB 页内能排布更多行，取决于列字节越小、页内行数越多、B+Tree 非叶节点能存更多索引项。
字节数决定取值 → TINYINT 1 字节 8 位，有符号 -128~127：为什么范围是 2^8 一半，因为最高位是符号位。
范围决定溢出行为 → 超范围时 MySQL 报错或截断：为什么生产必须用足够大的类型，因为上线后改列类型是 ALTER 大表加锁风险。

证据锚点（去重 ≥6）：

TINYINT=1 字节，有符号 -128~127，无符号 0~255
SMALLINT=2 字节，有符号 -32768~32767
MEDIUMINT=3 字节，有符号 -8388608~8388607
INT=4 字节，有符号 -2147483648~2147483647
BIGINT=8 字节，有符号 -9223372036854775808~9223372036854775807
UNSIGNED：去掉符号位，上限翻倍（如 INT UNSIGNED 到 4294967295）
ZEROFILL：数字左补零到显示宽度，MySQL 8.0.17 起废弃显示宽度但 ZEROFILL 仍有效
AUTO_INCREMENT：主键自增推荐用 BIGINT，避免 INT 溢出后 AUTO_INCREMENT 顶到上限

对比与权衡：

类型	字节	有符号范围	典型用途	失败边界
`TINYINT`	1	-128~127	状态码、布尔	状态枚举 >127 即溢出
`SMALLINT`	2	-32768~32767	小计数值	日活/小统计可能不够
`MEDIUMINT`	3	-8388608~8388607	中量级 ID	百万级 ID 仍够
`INT`	4	-21亿~21亿	常规主键/ID	自增到 21 亿溢出
`BIGINT`	8	±9.2E18	雪花/订单/流水主键	几乎不会溢出

常见误区：

错误：INT(11) 表示只能存 11 位整数 → 正确：括号是「显示宽度」，与存储字节/范围无关，MySQL 8.0.17+ 已废弃 → 为什么错：把 UI 展示宽度当成数据模型约束。
错误：整数类型占用的字节数随数值大小变化 → 正确：MySQL 整数列是定长，INT 恒 4 字节 → 为什么错：误解成变长存储（那是 VARCHAR 的事）。
错误：主键用 INT 就够 → 正确：订单/流水/雪花 ID 用 BIGINT，因为 INT 上限 21 亿，高并发自增很快顶到 → 为什么错：低估了写入量级，溢出后 ALTER 改列在大表上是锁表灾难。
错误：无符号能让负数不合法却更高效 → 正确：UNSIGNED 只改范围不改存储大小与性能，只是「负值被拒绝」 → 为什么错：以为 UNSIGNED 能提速，实则是约束语义。

适用边界：若业务 ID 由应用侧生成（雪花、UUID 数字版），或未来可能合并多库、跨库分片，直接 BIGINT，不要为省 4 字节在 INT/BIGINT 之间纠结——省下的是每行 4 字节，换来的是溢出重建表的系统性风险，不划算。

延伸追问（≥3）

为什么推荐主键用 BIGINT 而不是 INT？

要点：INT 上限 21.4 亿，自增主键在秒级高写入下很快逼近；雪花 ID 超过 21 亿直接溢出。
追问落点：溢出后 ALTER TABLE MODIFY 改列类型在大表上的锁与 DDL 成本。

UNSIGNED 和显示宽度分别影响什么？

要点：UNSIGNED 影响取值范围（上限翻倍）；显示宽度只影响展示补零。
追问落点：MySQL 8.0.17 后显示宽度废弃，只剩 UNSIGNED 有意义。

为什么不用 DECIMAL 存整数 ID？

要点：DECIMAL 是精确小数，存储更大、运算更慢，整数场景用整型更省。
追问落点：金额为什么用 DECIMAL 而 ID 不用——精度与范围的语义差别。

面试者参考回答（400–700 字）

【结论】 MySQL 整数类型按字节数递增为 TINYINT、SMALLINT、MEDIUMINT、INT、BIGINT，int 固定占用 4 字节、32 位。

【三点】 第一，字节数是固定的：TINYINT 1 字节、SMALLINT 2 字节、MEDIUMINT 3 字节、INT 4 字节、BIGINT 8 字节，定长存储让 InnoDB 页内能排布更多行、索引更紧凑。第二，范围由字节和符号位决定：INT 有符号上限 21 亿，加 UNSIGNED 翻倍到 42 亿；BIGINT 是 64 位，几乎不会溢出，所以订单/流水/雪花这类会持续增长的主键我直接上 BIGINT。第三，要区分显示宽度和存储字节：INT(11) 只是展示补零，MySQL 8.0.17 起已废弃，别把它当成能存 11 位——这是最常见的误解。

【边界】 如果业务 ID 是应用侧生成的雪花号或将来要跨库分片，就别在 INT 和 BIGINT 之间省那 4 字节，直接 BIGINT；否则自增顶到 21 亿后改列类型，在大表上是锁表级别的灾难。

面试记录 2026-10-29（第 1 次）

题目：MySQL中除了int整数类型整形还有哪些类型int类型占用

难度：low

标签：db/mysql/concepts, real-interview, difficulty/low

评分：⭐⭐⭐⭐☆（4/5）

练习次数：1

我的回答

mysql 中的整形 int 占用的空间是 4 个字节,32 位

除了 int 外还有占据 8 字节的 bigint,一般用来做数据库的主键 id

另外有最小的 1 字节 tinyint,2 字节的smallint,3 字节的mediumint

点评

优点：五种整数类型全对，字节数准确（1/2/3/4/8），并点出 BIGINT 用于主键 ID 的实践。

不足：未提 UNSIGNED/ZEROFILL、未区分显示宽度与存储字节。

补充：INT(11) 的括号是废弃的显示宽度；BIGINT UNSIGNED 更适合雪花/订单主键；主键选型在 INT 溢出后改列是大表 DDL 风险。

完整讲解见上方「完整讲解（权威版）」