MySQL整数类型避坑指南：TINYINT、INT、BIGINT怎么选才不出事

先聊个我印象很深的故障：那年一张线上订单表的累计状态值用的是 TINYINT，后来业务加了个新状态 299，当天半夜就开始疯狂报错，大量订单写不进去。排查半天，才发现不是程序 bug，是 TINYINT 有符号上限只有 127，你塞个 299 进去，严格模式下直接 Out of range。从那之后，我每次建表都会把 MySQL 数据类型里最容易出事的整数整明白：TINYINT、INT 和 BIGINT，谁也别想蒙混过关。这篇文章就是一次完整复盘，适合正在学 MySQL 的新人，也适合写业务代码的老手抽几分钟对照自查——很多问题不是不会写 SQL，而是建表那一刻类型就没选对。

MySQL 的整数类型永远不应该是“随手选一个”的事。TINYINT、INT、BIGINT 之间的差距，不只是名字长短，而是存储空间、取值范围、索引性能、甚至下游接口能不能接住的问题。下面我从底层差异讲起，把选型思路、实操细节、隐蔽坑点和排查手段一次说透。

1. 三种整数类型的核心差异：先从底层存储讲起

1.1 字节数、取值范围和内存成本，一张表算清楚

很多人知道 TINYINT 占 1 字节、INT 占 4 字节、BIGINT 占 8 字节，但从来没认真想过“为什么是这些范围”。这里有个最简单的算法：N 字节就是 8N 位，有符号类型最高位拿来做符号位，所以实际数值位是 8N-1 位。

• TINYINT：1 字节，8 位，有符号时最大值是 2^7 - 1 = 127，最小值是 -2^7 = -128。
• INT：4 字节，32 位，有符号时最大值是 2^31 - 1 = 2147483647，最小值是 -2147483648。
• BIGINT：8 字节，64 位，有符号时最大值是 2^63 - 1 = 9223372036854775807，最小值是 -9223372036854775808。

如果加上 UNSIGNED 关键字，最大值会往上翻一倍，下面是完整对照：

这些范围不是我背出来的，而是可以在 MySQL 里直接验证的。拿 INT 举例，你建一张临时表，插入 2147483647 没问题，插入 2147483648 就会在严格模式下报错：

sql复制CREATE TABLE t_int_check (
  id INT NOT NULL
) ENGINE=InnoDB;

INSERT INTO t_int_check(id) VALUES (2147483647);
INSERT INTO t_int_check(id) VALUES (2147483648);
-- ERROR 1264 (22003): Out of range value for column 'id' at row 1

这里必须提醒一句：只有数字“刚好落在类型范围内”才是安全的，边界值很容易被忽略。曾经有同事把年份存在 TINYINT 里，等系统跨过 127 年当然不可能，但他存的是“用户年龄”也没问题，问题是他把“用户来源渠道编号”塞 TINYINT，渠道一多就爆。存什么值，决定你选什么类型，而不是反过来。

1.2 为什么不能为了省事全部用 BIGINT

有人会想：既然 BIGINT 范围最大，那不管什么字段都建 BIGINT 不就好了？我以前也这么干过，直到一张千万级流水表因为全字段 BIGINT 导致索引体积变大，查询性能和磁盘成本一起上来，才意识到问题没那么简单。

数据库的存储成本是“行数 × 字段字节数”放大出来的。假设一张表有 1 亿行，某个状态字段从 TINYINT（1 字节）升级成 BIGINT（8 字节），仅这个字段就多占 7 亿字节，约 670MB。如果表里有五六个整数字段，多出来的就是几个 GB 的量级。更关键的是，二级索引会复制主键值，主键越大，每个二级索引页能容纳的条目越少，随机 IO 更频繁，查询自然变慢。

你可以用一个查询对比同一张表下不同数据类型的实际差别：

sql复制SELECT
  table_name,
  ROUND(((data_length + index_length) / 1024 / 1024), 2) AS total_mb
FROM information_schema.tables
WHERE table_schema = 'your_db'
  AND table_name IN ('t_tinyint_demo', 't_bigint_demo');

结论很简单：能用 TINYINT 的地方别用 INT，能用 INT 的地方别用 BIGINT，但该上 BIGINT 时也别抠那 4 个字节。选类型本质是“按需分配”，不是越大越好。

2. 业务场景选型思路：什么时候用 TINYINT，什么场景直接上 BIGINT

2.1 状态位、枚举和开关字段优先用 TINYINT

业务系统里最常见的一类整型字段是“状态”，比如订单状态、支付状态、审核状态、逻辑删除标记。这些值通常只有 0、1、2、3 几个档位，用 TINYINT 是教科书级别的选择。为什么不用 INT？因为没意义，一个 4 字节的 INT 能存 21 亿，而状态字段真正用到的最小值通常不超过两位数，剩下的空间全部浪费。

具体使用上，我更推荐“有符号 TINYINT + 预留负数语义”或者“无符号 TINYINT + 从 0 开始编码”两种风格。比如支付渠道状态，我习惯这样定义：

如果不希望负数出现，就用 TINYINT UNSIGNED，范围是 0~255，对一般状态码足够。这里有第一个容易踩的坑：不要把 TINYINT(1) 和“布尔值”画等号。MySQL 里其实没有原生的 BOOLEAN 类型，你写 BOOLEAN 也会被转成 TINYINT(1)，但它照样能存 2、3、4 这些值。所有“它是布尔所以只能存 0 和 1”的幻想，都属于自作多情。

有一次排查线上问题时，我看到某张表的 state 字段是 TINYINT(1)，程序里按 Boolean 处理，代码是 if (state) 这种写法。后来产品新增需求，需要区分“已读”“未读”“删除”，开发直接把 2 塞进去，结果所有判断全部走错分支。这个案例充分说明：状态值字段设计时就要想好未来会不会扩展，枚举量的上限决定了到底用不用 UNSIGNED，以及要不要预留足够空间。

2.2 常规业务主键、计数器和统计量用 INT？先算一下数据量

INT 最经典的战场是业务主键、用户 ID、常规计数。有符号 INT 上限 21 亿多，看起来很多，但选型不能凭感觉，得算业务生命周期。

举个例子：一张用户行为日志表，高峰期一天写入 100 万条，一年就是 3.65 亿条。如果主键用 INT，理论上 5 到 6 年就可能撞到 21 亿的上限。但同一张表如果只是存系统配置，一天写入几条，那 INT 就非常够用。

还有一类“隐形的暴增”往往被忽略：删除数据不会让自增主键回退。你表里现在只有 100 万行，不代表自增 ID 只有 100 万。InnoDB 的自增计数器一旦涨上去，即使把最大 ID 的行删掉，再次插入时一般也不会复用那个旧值。很多 DBA 遇到过这种情况：某张表行数才几百万，但 AUTO_INCREMENT 已经跑到 2 亿，因为历史上发生过频繁的插删、批量导入回滚。这就是为什么单看 COUNT(*) 不能判断 INT 主键的安全余量。

如果你拿不准，可以直接查当前自增值：

sql复制SHOW TABLE STATUS LIKE 'your_table';
-- 看 Auto_increment 列

然后用这个值和 2147483647 做差，大概估算剩余量。如果剩余量不足未来三年的写入量，建议尽早考虑升级 BIGINT。因为早期改类型只是在建表语句上动一下，等数据量大了再 ALTER TABLE，动辄锁表几小时，风险很高。

2.3 分布式ID、日志、流水等场景：BIGINT 是唯一选择

互联网业务发展到一定规模，都会抛弃单库自增主键，改用雪花 ID、号段模式一类分布式 ID。这类 ID 通常是 64 位整数，比如雪花算法生成的 ID 会落在 BIGINT 范围内，这时表主键直接上 BIGINT，没有讨论余地。

这时候如果你还用 INT，插入时并不会立刻报错，而是当 ID 超过 2147483647 才开始炸。更麻烦的是，你在代码里根本看不出来，因为 Java 的 Long 类型能存下雪花 ID，数据库却存不下，所有写入都变成 Out of range。这种问题出现在大促、高并发期间会非常被动，因为你临时去 ALTER TABLE 改主键类型，成本极高。

日志流水表、订单流水表、操作记录表这一类“只增不减、量大且生命周期长”的表，主键和流水号我基本无条件选 BIGINT。哪怕当前量级不大，也要为未来留出余量。还有一种做法是拆成“业务订单号”和“自增主键”两个字段，业务订单号用字符串或 BIGINT，自增主键用来维护索引聚簇结构，这样两边的压力都能缓解。

选型时可以参考这张决策表：

3. 实操过程中最容易翻车的细节

3.1 INT(11) 的显示宽度并不限制存储值

面试里我经常问一个问题：INT(11) 和 INT 有什么区别？十个有八个答“INT(11) 最多只能存 11 位数字”，这是完全错误的认知。INT 不管写不写括号里的数字，存储空间都固定 4 字节，能存的最大值都由符号位决定，不会因为括号里写 3 就能少存，也不会因为写 20 就能多存。

这个括号里的数字叫“显示宽度”，它只在特定客户端配合 ZEROFILL 属性时影响展示效果。比如 INT(5) ZEROFILL，插入 42 之后查询可能显示为 00042，只是补零展示，底层存储的还是 42。MySQL 8.0.17 之后官方其实已经不建议再为整数类型声明显示宽度了，新项目里没必要写 INT(11) 这种老古董写法。但从 5.7 老库迁移过来的人会看到很多历史建表语句里带着它，了解它不影响存储这个事实很重要，否则你可能会被误导，以为某字段限制了位数，结果插入大数字后照样超出范围报错。

有一个真实案例：开发把手机号字段定义为 INT(11)，以为 11 位正好对应手机号长度。结果手机号一旦存入，第一位为 0 的情况直接丢失，比如 0138 开头的号码变成了 138。更离谱的是，当手机号超过 21 亿这种量级后，INT 根本无法容纳，整个插入就开始报错。所以这里必须反复强调：凡是需要保留前导零的编号，一律不要用整数类型。

3.2 UNSIGNED 的取舍：能帮人也能坑人

UNSIGNED 表示“无符号”，也就是只能存非负数。很多人在设计年龄、数量这类字段时习惯写成 TINYINT UNSIGNED，这样 0~255 的范围确实比有符号更实用。但用到主键或参与运算的字段时，UNSIGNED 会带来一系列麻烦，需要谨慎。

MySQL 官方文档其实一直不建议对主键使用 UNSIGNED 吗？并非如此，但实践中我会尽量避免主键用 UNSIGNED，主要原因是上下游一致性。很多 ORM 和编程语言里的整数类型是有符号的，比如 Java 的 long 最大是 9223372036854775807，而 BIGINT UNSIGNED 的最大值是 18446744073709551615，如果你在数据库里定义了 UNSIGNED BIGINT 主键并塞入一个超过 Java long 范围的值，后端读到一半就可能出问题，JSON 序列化更是一团糟。

另外，UNSIGNED 字段参与减法运算时也容易出幺蛾子。比如执行 SELECT CAST(-1 AS UNSIGNED);，结果会变成一个很大的正数。业务代码一旦对这类字段做差值计算，很容易得到“离谱”的结果。所以，除非字段语义上确实不可能为负，否则默认使用有符号类型，真需要非负约束时，在应用层做好参数校验，远比依赖数据库 UNSIGNED 更稳妥。

如果你想验证自己库里有多少 UNSIGNED 字段，可以查 information_schema：

sql复制SELECT table_name, column_name, column_type
FROM information_schema.columns
WHERE table_schema = 'your_db'
  AND column_type LIKE '%unsigned%';

这样做的好处是给全库做个“体检”，尤其要警惕那些参与加减乘除的 UNSIGNED 列。

3.3 自增主键逼近上限之前，DBA 都在看什么

INT 自增主键达到 2147483647 之后，并不是“数据库自动扩容”，而是直接写不进去。MySQL 对自增列的类型是固定的，它不会因为达到上限就把 INT 变成 BIGINT。所以 DBA 在日常巡检中会关注两张核心指标：当前 AUTO_INCREMENT 值，以及最大允许值之间的距离。

有一个挺隐蔽的现象：InnoDB 引擎里，自增主键一旦用过，删除行并不会让引擎重置自增计数器到当前最大行 ID。比如你插入到 10 万，然后 DELETE 掉最后 5 万行，继续插入时新 ID 不是 50001，而是 100001。所以，如果一张表频繁做“导入—回滚—再导入”的操作，自增 ID 可能很快逼近 INT 上限，但表里实际行数并不多。

再往前一步，如果自增 ID 已经达到 2147483647，之后会发生什么？严格模式下插入会报 Out of range，非严格模式下可能插入成功但值被截断，导致主键冲突或其他无法预料的数据错乱。我的建议是：给自增主键设置监控告警，一旦 AUTO_INCREMENT 超过上限的 70%，就要启动类型升级流程。虽然 ALTER TABLE 在大表上很痛苦，但总比业务停摆好。

升级语句本身不复杂：

sql复制ALTER TABLE your_table MODIFY COLUMN id BIGINT NOT NULL AUTO_INCREMENT;

但执行前务必确认磁盘空间、主从延迟和锁表时间，最好在低峰期操作，先在从库上试跑，再切换主从。

4. 类型转换与跨端传值：这些坑比选错类型更隐蔽

4.1 隐式类型转换让索引失效，也让你查错数据

整数类型本身不会隐式转换出问题，但只要你的查询涉及“整数字段与字符串比较”或“字符串字段与整数比较”，数据库就会自动做类型转换，而这个转换往往会毁掉索引。

举一个最常见的场景：user 表里 mobile 字段是 VARCHAR(20)，你执行：

sql复制SELECT * FROM user WHERE mobile = 13812345678;

MySQL 会尝试把 mobile 列从字符串转成数字进行比较，导致 mobile 字段上的索引无法正常使用，因为列上发生了隐式函数转换。更隐蔽的是，如果字符串里包含非数字字符，比如 13812345678abc，在转成数字时可能被解析成 13812345678，于是你查 mobile = 13812345678 时，居然能把这条脏数据也查出来。这在电话号码、银行卡号、订单号场景里非常危险。

反过来，如果字段是 INT/BIGINT，条件写成 WHERE id = '123456'，数据库一般是把右侧字符串转成数字，整型字段本身不做转换，通常还能走索引。但为了可读性和可维护性，我建议写 SQL 时保持两侧类型一致，不要依赖数据库的“好心”。还有一个更隐蔽的坑是 JOIN 时关联字段类型不一致，比如左表 id 是 INT，右表 user_id 是 VARCHAR，关联条件会触发全表扫描，大数据量下直接把数据库拖垮。排查方法很简单，用 EXPLAIN 看 key 列和 rows 列，如果明明有索引却没走，优先怀疑隐式转换。

可以通过这种方式验证 MySQL 对字符型数字的转换规则：

sql复制SELECT CAST('138abc' AS SIGNED);
-- 结果通常是 138

这种“宽容”的转换逻辑，恰恰是脏数据进来的窗口。因此，涉及对外查询的整数条件，前端传入的参数最好在应用层先做类型校验，别把一个字符串原样拼进 SQL。

4.2 BIGINT 传到前端为什么会变成“假数据”

这是我在实际项目里踩过的最深的一个坑，也与热点问题“后端 bigint 前端怎么传值”直接相关。BIGINT 能存最大 9223372036854775807，但 JavaScript 的 Number 类型安全整数范围只有 -9007199254740991 到 9007199254740991，也就是 2^53 - 1 附近。超过这个范围，前端解析 JSON 时数字精度就会丢失。

举个例子：后端返回订单号 715900000000000001，前端用 JSON.parse 接收，实际拿到的可能是 715900000000000000。两个订单号不一样，但前端却把它们当成同一个值去处理，轻则显示错误，重则触发重复提交、缓存错乱。这在涉及分布式 ID、雪花 ID 的系统里非常常见。

解决办法不是让前端换语言，而是后端在序列化阶段就把大整数转成字符串。Java 项目里可以用 Jackson 全局配置：

java复制Jackson2ObjectMapperBuilderCustomizer customizer() {
    return builder -> {
        builder.serializerByType(Long.class, ToStringSerializer.instance);
        builder.serializerByType(Long.TYPE, ToStringSerializer.instance);
    };
}

或者在 ID 字段上单独加注解：

java复制@JsonSerialize(using = ToStringSerializer.class)
private Long orderId;

Go 项目里则可以在 json tag 里加 string 选项。这么做之后，前端拿到的订单号就是字符串，数据库中始终是 BIGINT，既保留计算能力，又不丢失精度。这里想强调一句：不是你数据库字段选了 BIGINT 就完事，跨端传输的数据类型链路要整体设计。

4.3 ORM 映射与 TINYINT(1) 的暧昧关系

Java 后端最常见的映射关系是：Integer 对应 INT，Long 对应 BIGINT。但 TINYINT(1) 在一些 ORM 框架或 JDBC 驱动里会被特殊处理，甚至被自动映射成 Boolean。这会导致你明明从数据库读到一个 TINYINT 值 2，程序里却把它当成 true，然后做了一堆错误的业务判断。

MySQL Connector/J 里有一个参数 tinyInt1isBit，默认是 true，意味着 TINYINT(1) 会被当作 BIT 处理，Java 里读出来可能直接是 Boolean。如果想要更常规的整数映射，可以在 JDBC URL 上追加：

text复制jdbc:mysql://localhost:3306/your_db?tinyInt1isBit=false

但更一劳永逸的做法是建表时就不写 TINYINT(1)，直接写 TINYINT，避免让驱动做“自作聪明”的解释。ORM 映射前，最好先查一下 information_schema 确认字段的真实类型，不要看到程序代码里写着 Boolean 就信了数据库真存的是布尔值。

如果项目里已经有一堆 TINYINT(1) 字段，并且你确实想当整数用，可以在建表时用 BIT(1) 表达布尔语义，状态位则统一用 TINYINT 不带显示宽度。这样字段的语义清晰，程序里也好维护。

5. 常见问题速查与排错实录

5.1 Out of range、Data truncation 等报错现场

我在支持别人的过程中，发现很多和数据长度相关的问题，最终都归结为同一种类型不匹配。下面整理几个高频现象，可以直接对照排查：

排错时，先看 SHOW WARNINGS; 能拿到更精确的报错信息。很多新手只盯着应用程序日志，其实服务端错误日志和 MySQL 的 Warnings 会直接告诉你数据是哪一步被截断的。还有个小技巧：使用 SELECT * FROM your_table ORDER BY id DESC LIMIT 1; 看当前最大自增 ID，再用 SHOW TABLE STATUS 看 Auto_increment，两者差距过大说明有大量删除历史，自增余量要按 Auto_increment 计算而不是按行数计算。

5.2 一张“该不该换 BIGINT”的体检清单

如果你正在维护一张老表，主键是 INT，但我前面这些场景让你隐隐不安，可以用一份自查清单快速评估：

1. 日新增量有多大？未来三年预计总行数是否接近 20 亿？
2. 表是否存在频繁插入后删除、批量导入回滚的情况？
3. 当前 AUTO_INCREMENT 是否已超过 15 亿？
4. 是否存在分布式 ID 接入计划？微服务化之后是否要跨库生成主键？
5. 是否有前端页面直接读取该表 ID 并参与运算？
6. 是否已经出现过 Out of range 报错，哪怕只出现一次？

如果上述问题里有任意一项命中，建议尽早把主键类型升级为 BIGINT。大表改主键确实成本高，但它的高风险也高；相比之下，今天不改，明天出故障时再改才是更大的代价。同时可以把字段默认值、注释、字符集等一并检查清楚，减少反复变更次数。

升级完成后，用一段简单 SQL 验证数据回读：

sql复制SELECT MAX(id), COUNT(*) FROM your_table;

确保 MAX(id) 能正常显示且没有负数、重复值。更保险的做法是升级前先做逻辑备份，升级后对比源库和目标库的记录数、校验和。

5.3 几条关于整型字段的实战经验

最后分享几条我用血泪换来的规矩，算不上什么标准答案，但至少能让你以后少走弯路。第一，建表前先问自己三个问题：这个字段存的是什么？未来可能的最大值是多少？有没有下游系统要消费这个值？三个问题回答完，选什么类型基本就清楚了。第二，状态、枚举、布尔建议成体系管理，不要光靠一个 TINYINT 字段打天下，建议在代码里定义枚举类，数据库层写明注释，避免后人看着 0、1、2 发呆。第三，所有整型字段都要预估“删除是否频繁”。如果这张表可能天天有人删数据，自增 ID 的消耗速度会比想象中快很多，这时候 INT 的安全余量要打个大折扣。第四，所有涉及 BIGINT ID 的下游接口，默认输出为字符串，这是前后端协作的基本素养。

我个人在实际操作中最喜欢的一个小技巧是，用一条 SQL 快速找出全库里所有整型字段的分布情况：

sql复制SELECT
  table_name,
  column_name,
  column_type
FROM information_schema.columns
WHERE table_schema = 'your_db'
  AND data_type IN ('tinyint', 'int', 'bigint')
ORDER BY table_name, ordinal_position;

拿到这个清单后，我会按“状态位优先 TINYINT、常规主键尽量 INT、分布式和流水场景无脑 BIGINT”的顺序，对每一个字段做一次人工复核。这个过程不需要多高深的技术，但能有效避免建表时的“随手选”。

很多人以为数据类型只是建表时的一行代码，等到出现 Out of range、索引失效、前端精度丢失时才意识到，这其实是整个数据链路的基石。选对 TINYINT、INT 和 BIGINT，不只是让数据库能存下数据，更是让你未来几年的业务迭代中少几次凌晨三点的告警电话。