我在做后端开发的时候最常被新人问倒的问题之一就是建表的时候用户ID到底用 INT 还是 BIGINT一个状态字段用 TINYINT 会不会不够明明都是整数MySQL 为什么要分 TINYINT、INT、BIGINT 这么多种类说实话这些基础问题看起来简单但选错了代价很大——轻则白占存储空间重则字段溢出、数据写入失败线上事故就是这么来的。这篇东西我就把自己这些年对 MySQL 整数类型的理解和实操经验梳理一遍从存储原理讲到具体的业务选型再聊几个容易踩的坑。适合刚接触数据库设计的同学通读一遍也适合写过一阵子但没系统整理过类型体系的开发者用来查漏补缺。1. 整数类型的基础认知存储、范围与业务直觉1.1 字节数才是类型的本质MySQL 里整数类型最大的区别不在于“能存多大数”而在于“占多少字节”。TINYINT 占 1 个字节INT 占 4 个字节BIGINT 占 8 个字节。这背后是计算机存储的基本单位1 个字节等于 8 个比特位能表达 2 的 8 次方也就是 256 种组合。所以 TINYINT 理论上可以表示 0 到 255无符号或者 -128 到 127有符号它的取值范围直接由比特位数决定。同样地INT 用 32 个比特位BIGINT 用 64 个比特位。这些数字很多人在大学课本里见过但真正理解它的人不多——类型选型的本质就是在“够用”和“省空间”之间找平衡点。举一个直观的例子如果一个表有 1 亿行数据某个字段从 INT 改成 TINYINT每行省 3 个字节总共省下约 286 MB 的存储空间。如果这张表还有几个二级索引那节省的就不只是行数据本身还包括索引占用的空间。反过来如果一个字段用 TINYINT 但业务值可能会超过 127那就等着线上写数据时报 Out of range 错误吧。1.2 取值范围的计算方法看懂就够了我见过不少开发者记不住各类型的范围每次都去查手册。其实只要记住一个公式有符号范围负半轴是 -2^(n-1)正半轴是 2^(n-1)-1无符号范围是 0 到 2^n-1其中 n 是比特位数。TINYINT8 位有符号 -128 到 127无符号 0 到 255INT32 位有符号 -2147483648 到 2147483647无符号 0 到 4294967295BIGINT64 位有符号 -9223372036854775808 到 9223372036854775807无符号 0 到 18446744073709551615为什么正半轴要减 1因为 0 占了其中一个位置。这个细节很多人在计算时容易漏掉比如 INT 的正半轴很多口头描述说“21亿”精确值其实是 2147483647。我把这三类最常用的整数类型整理成一个速查对照表方便建表时直接瞟一眼类型字节数有符号范围无符号范围典型用途TINYINT1-128 ~ 1270 ~ 255状态码、开关、性别、删除标记SMALLINT2-32768 ~ 327670 ~ 65535小范围计数、枚举值扩展MEDIUMINT3-8388608 ~ 83886070 ~ 16777215中等长度计数INT4-2147483648 ~ 21474836470 ~ 4294967295常规ID、计数器、普通数值BIGINT8约 -9.22e18 ~ 9.22e180 ~ 约 1.84e19雪花ID、超大数据量主键、金额分顺带说一句SMALLINT 和 MEDIUMINT 也是很常用的只是标题里重点讲 TINYINT、INT、BIGINT 这三兄弟。实际工作中 SMALLINT 适合放枚举值扩展场景MEDIUMINT 相对冷门一些我曾经在一个数据量巨大的日志表里用它存储请求耗时毫秒级效果也很好。1.3 有符号还是无符号别想当然在 MySQL 中整数类型默认是有符号的SIGNED但你可以显式声明为无符号UNSIGNED。什么场景下用 UNSIGNED最常见的判断标准就是业务值是否可能出现负数。如果字段存的是“价格差额”可能出现负数必须用 SIGNED如果字段存的是“库存数量”“点击次数”“IP地址段”永远不会为负数用 UNSIGNED 可以在同等字节下把正数上限翻倍比如 TINYINT 有符号上限 127改成 UNSIGNED 后上限变成 255。INT UNSIGNED 的上限是 42.9 亿刚好是 INT 有符号上限的两倍这对于一些不能轻易用 BIGINT因为存储空间和索引宽度都更大的场景很有吸引力。但是我也要提醒如果某天业务需求变化原本非负的字段要支持负数那么 UNSIGNED 就会成为限制。我在实际项目里见过一个教训某个计数器字段用 INT UNSIGNED后来产品要做“余额增减”余额可能变成负数结果数据库层直接写不进去最后只能改字段类型加迁移脚本。所以无符号的选择要考虑未来业务边界不能只看当下。另外在 JOIN 关联时两个表的关联字段类型最好完全一致包括有符号无符号也必须一致。如果一张表是 INT UNSIGNED另一张是 INT SIGNEDMySQL 要做隐式转换往往会导致索引失效、全表扫描。这一点很多人写 join 语句时根本没注意以为是相同类型就万事大吉了。2. 别被 INT(11) 骗了显示宽度与存储大小无关2.1 括号里的数字到底有什么用很多从 Navicat 或旧版建表脚本里看到INT(11)的人会误以为 11 表示这个字段最多只能存 11 位数字。这是一个流传很广的误解必须纠正。INT(11)中的 11 是“显示宽度”display width它只在两个条件下有效果字段设置了 ZEROFILL零填充并且查询结果需要按固定宽度显示。它不限制存储范围——INT 不管写 INT(11) 还是 INT(3)取值范围都是完全一样的 21.47 亿上限。也就是说括号里的数字不影响你能存多少数据也不影响存储空间。比如一个字段定义为TINYINT(2) UNSIGNED ZEROFILL你插入一个 5查询出来显示为 05但实际存储值仍然是 5。这只是展示层面的补零效果。2.2 显示宽度的实际应用场景那 ZEROFILL 在什么场景下有用比较经典的是一个订单号场景要求编号固定 8 位不足 8 位前面补零。如果业务上允许用自增数字且不超过 99999999那么定义INT(8) UNSIGNED ZEROFILL就能在查询时自动显示成00001234。但我个人的建议是除非有很强的展示需求否则不要依赖数据库层的 ZEROFILL。原因有三个ZEROFILL 会影响存储和比较在 MySQL 中启用 ZEROFILL 的列会被隐式加上 UNSIGNED 属性这可能导致负数场景出问题展示格式化属于表现层逻辑应该由后端代码处理比如在 SQL 查询后用字符串补零函数或直接在接口层处理不同版本的 MySQL 对显示宽度的支持细节有差异比如 8.0 已经弃用了部分显示宽度语法后面维护容易踩坑2.3 新版本建表时怎么写最稳妥现在写 SQL 建表我推荐直接用不带括号或带标准宽度的写法。比如CREATE TABLE order_info ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 主键ID, order_no VARCHAR(32) NOT NULL COMMENT 业务订单号, status TINYINT NOT NULL DEFAULT 0 COMMENT 订单状态: 0待支付 1已支付 2已取消, user_id BIGINT NOT NULL COMMENT 用户ID, PRIMARY KEY (id), KEY idx_user_id (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单表;关于括号数字我的经验是既然不限制存储长度就没必要写得花里胡哨。MySQL 8.0 已经在逐步弱化整数显示宽度的语义建议新项目在定义表结构时就统一风格写出没有歧义的 DDL 脚本。3. 实战选型指南不同业务场景到底该选哪个3.1 主键字段从 INT 到 BIGINT 的抉择自增主键是所有 MySQL 表中最常见的整数应用。我见过无数张表用INT AUTO_INCREMENT一般业务下没问题但有个隐患INT 有符号上限 21.47 亿无符号也才 42.9 亿。看着很大但是对于日志流水、用户关系、交易记录这类高频插入的表达到这个量级并不是不可能。关键点在于INT 主键涨到上限后再插入数据就会主键溢出整张表不可写入。这个事故一旦发生扩容非常麻烦不光是改字段类型还要重建索引、处理缓存业务中断时间你根本预估不出来。所以我的建议是凡是主键直接上 BIGINT不要犹豫。有人觉得 BIGINT 比 INT 多 4 个字节存储和索引都变大但在绝大多数业务下这点空间换来的是几十年的增长余量非常划算。尤其是 MySQL InnoDB 引擎中二级索引都会包含主键列所以主键越大每个二级索引也会相应增大。可是相比于主键溢出的运维灾难多出来的存储开销完全可接受。执行 ALTER TABLE 修改主键类型时有个细节要提醒在线 DDL 虽然支持 MODIFY COLUMN但修改主键类型往往意味着重建表在亿级大表上执行时极可能锁表或产生巨大 IO 压力。我建议选择业务低峰期操作或者用 gh-ost 这类工具做在线变更并提前备份。3.2 状态类字段TINYINT 的好处比你想象的多应用层最常见的枚举字段订单状态、用户状态、逻辑删除标记、性别、消息是否已读。这类字段取值范围很小可能就 0 到 10 的几种状态用 TINYINT 是唯一的正解。为什么不用 INT原因很简单TINYINT 只占 1 字节INT 占 4 字节。一张订单表可能几千万行三个状态字段加起来每行省 9 字节整表省下几百 MB 的磁盘和内存缓冲池缓存行数据时同样受益。这段优化几乎是零成本的。另一个容易被忽略的点TINYINT 对代码规范有积极影响。因为它范围小你在写后端枚举转换时会下意识地去维护一个完整的映射表。如果字段是 INT可能有人就把魔法数字散落在代码里。虽然这不是数据库本身的问题但类型设计确实会影响团队的编码习惯。建议在枚举字段上加上注释把每个数字的含义写清楚例如status TINYINT NOT NULL DEFAULT 0 COMMENT 0-待支付 1-已支付 2-已退款 3-已关闭这样其他同事接手时不用去翻代码就能明白业务含义也避免了一个数字在不同表里代表不同含义的混乱。3.3 中频数值与计数器INT 的主场当数值范围超过 255、但又明显远小于 21 亿时INT 是最常见的选择。典型的场景包括文章的阅读数、商品的库存量、用户的积分余额、某个资源的总下载次数、消息队列里的重试次数等。这类字段的核心特点是值会增长可能到千万级甚至上亿但很少超过 21 亿。如果你预期极限值可能在 10 亿这个量级我建议认真评估一下是否应该用 BIGINT因为 INT 无符号上限是 42.9 亿而有符号上限才 21.47 亿。假设一个热门视频播放量能到 20 亿你用的是 INT SIGNED那就位于危险边缘了。还有一个容易忽略的点用 UPDATE 语句做自增时一旦值溢出语句会直接报错而不是自动封顶。比如UPDATE video SET play_count play_count 1 WHERE id 123;如果 play_count 已经接近 INT 上限这个更新就可能失败。所以计数器字段在预估波动大时宁可直接用 BIGINT省得后面再改表。3.4 超大数值与分布式IDBIGINT 的专属场景BIGINT 的典型应用场景包括雪花算法生成的分布式 ID、超大数据量的主键、需要精确存储的大整数、某些系统时间戳等。雪花 ID 是一个典型的必须用 BIGINT 的例子。雪花算法生成的结果通常是 64 位整数往往会超过 INT 的 42.9 亿上限如果建表时用 INT 去接数据直接溢出报错。我见过有人把所有表主键统一设计成 BIGINT就是为了给未来接入分布式 ID 留好余地。另外一个容易被忽略的场景是时间戳。某些系统设计里时间戳用毫秒级存储成一个整数比如 2025 年的毫秒时间戳大约是 1700000000000 这个量级远远超过 INT 的 21 亿。如果存到 INT 字段结果就是写入失败。所以当你在建表时看到“time_value”“ts”这类字段先确认它是秒级还是毫秒级再决定类型。4. 容易踩坑的细节类型转换、溢出与隐式陷阱4.1 条件查询里的字符串与整型隐式转换这是实战中出现频率最高的坑之一。假设某张表的user_id字段是 BIGINT你在代码里拼 SQL 时不小心传了一个字符串比如SELECT * FROM user WHERE user_id 123abc;MySQL 会把字符串转换成数字再比较。如果这个字符串不是纯数字转换时可能出现警告而且更严重的是如果字段本身是字符串类型而传入的是数字也可能会使索引失效。不过对于整型字段更多的问题出在另一侧——你把字符串类型的字段和数字比较就会导致字段上的索引失效。这些坑虽然不属于 TINYINT、INT、BIGINT 内部的问题但恰恰是整数类型使用中最常见的隐患。我建议所有写查询的同事都要保持字段类型和传入参数类型的一致性。尤其在 MyBatis 之类的框架里动态 SQL 容易因为参数类型没写对而触发隐式转换。出现慢查询时用 EXPLAIN 看一下 key 列和 rows 列如果明明建了索引却走了全表优先排查类型是否一致。4.2 数值溢出静默与报错的边界在 MySQL 的不同模式下数值溢出的表现不太一样。默认情况下如果给一个 TINYINT 字段插入 200MySQL 会在非严格模式下把值截断为 127 或 255并产生一个警告而不是报错。在严格模式sql_mode 中包含 STRICT_TRANS_TABLES下插入超出范围的值会直接报错。实际生产中我强烈建议开启严格模式默认的宽松模式会让数据悄悄变坏等到查数时才发现不对那时候已经很难追溯了。检查当前会话的 sql_mode 可以执行SELECT sql_mode;如果发现没有 STRICT_TRANS_TABLES可以加上。修改方式可以写在配置文件或会话中执行SET SESSION sql_mode STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION;注意这个修改只在当前会话有效持久化要改配置文件并重启实例。这也是一个我面对新环境时首先会检查的项目。4.3 整型与 DECIMAL、FLOAT 的边界意识有些人会在金额字段上用 BIGINT以“分”为单位存储整数金额这是一种常见的做法优点是不会出现浮点误差。但要注意金额计算如果涉及汇率换算结果可能是小数用 BIGINT 存储时要么四舍五入要么拆成两个字段。与此相对的不要用 FLOAT/DOUBLE 来存需要精确比较的数值会有精度问题。如果确实要用小数DECIMAL 才是合适的选择。这些内容虽然不是整型本身但选型时要把它们放在同一张决策表里考虑。我在一个项目中曾见过这样的设计用户余额用 DECIMAL(10,2)积分用 INT折扣用 FLOAT。结果折扣计算时因为 FLOAT 精度问题导致积分数值出现偏差排查了很久。总结一句话需要精确十进制运算时选 DECIMAL需要连续数值计算时考虑 DOUBLE但无论如何别把金额、积分这类关键业务数值让给浮点类型。4.4 综合性避坑清单把上面提到的坑整理成一张速查表方便建表评审和排查问题时对照常见问题典型表现解决办法整型字段溢出insert/update 报 Out of range value预估数据量直接上 BIGINT关联字段类型不一致JOIN 慢、索引失效统一两表字段类型和有符号属性整数类型当字符串比较查询结果异常或索引失效保持参数类型与字段类型一致状态字段用 INT存储空间浪费、枚举易乱无脑用 TINYINT 就好显示宽度误用误以为限制长度抛弃 INT(N) 思维8.0 后更应简化写法自增主键用 INT数据量大后溢出风险新表主键全部用 BIGINT非严格模式截断数据悄悄变小开启 STRICT_TRANS_TABLES5. 代码层的类型映射从数据库到应用的一一对应5.1 各语言里 TINYINT、INT、BIGINT 对应的类型建表选型只是第一步应用层读取数据时要选用匹配的数据类型。这里如果映射错了同样会踩坑。在 Java 中TINYINT 映射为 Byte 或 ShortINT 映射为 IntegerBIGINT 映射为 Long。如果数据库字段是 BIGINT但你在实体类里用 Integer 接收查询结果超过 21 亿就可能直接被 MyBatis 转成负数或报转换异常。另外使用 ResultSet.getInt() 读取 BIGINT 字段也可能溢出建议读取大整数时使用 getLong()。在 Go 中TINYINT 对应 int8但为保险起见通常扫描到 int 也没问题INT 对应 int32 或 intBIGINT 对应 int64。如果你在 GORM 里用 int 接 BIGINT 字段在 32 位系统上会溢出。Python 的 int 是变长的反而没有这些问题但 ORM 内部仍可能对长度有约束。无论什么语言原则很简单应用层的数值类型范围一定要能覆盖数据库字段的取值范围。5.2 自增主键与 ORM 的配合有的团队会在后端代码里自己生成主键而不是依赖数据库自增。常见的做法是用雪花算法生成一个 BIGINT 主键这种 ID 因为不是一个连续的递增序列对 InnoDB 的索引页写入会产生一定随机性。所以很多系统会采用“BIGINT 自增主键 业务ID唯一索引”的设计兼顾写入性能与业务查询需求。如果你用的是 ORM 框架插入后需要回填自增主键。在 MyBatis 中使用useGeneratedKeystrue可以拿到自增 IDJPA 则通过GeneratedValue配合GenerationType.IDENTITY。这些场景下主键类型要和数据库定义完全一致才能避免精度损失。比如数据库用 BIGINTJava 实体用 Long那么 MyBatis/JPA 回填的类型也要是 Long。5.3 数据同步与跨库对比时不要丢精度BIGINT 的最大值是 9223372036854775807这个数字有 19 位而 JavaScript 的 Number 安全整数上限是 900719925474099116 位。所以如果你在前端页面直接展示后端传过来的 BIGINT 主键就可能发生精度丢失。比如某个 ID 是 17612345678901234567前端拿到后变成 17612345678901234000再往后端传就完全对不上了。这个问题在电商、社交等场景里很常见解决办法有两个一是把 BIGINT 主键序列化成字符串传给前端二是干脆在应用中额外生成一个 String 类型的业务编号比如订单号作为前端交互的主键。我个人更推荐后者因为字符串业务主键更灵活而且可以内置业务规则比如日期加序号。另外一个场景是跨数据库同步。从 MySQL 同步到其他数据库或数据仓库时如果目标库没有 BIGINT 类型只能把这类字段定义为 DECIMAL 或字符串否则就会丢精度。数据同步时最好加个校验环节对比源和目标的最大值、最小值、总数早发现问题早处理。6. 实际表结构案例与设计思路复盘6.1 一个完整的订单表设计案例与其零散地讲不如直接给一个案例。假设我们设计一张电商订单表核心字段如下CREATE TABLE trade_order ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 自增主键, order_id VARCHAR(32) NOT NULL COMMENT 业务订单号(对前端展示), user_id BIGINT NOT NULL COMMENT 用户ID(雪花ID), shop_id BIGINT NOT NULL COMMENT 店铺ID(雪花ID), status TINYINT NOT NULL DEFAULT 0 COMMENT 订单状态 0-待支付 1-已支付 2-已发货 3-已完成 4-已取消, refund_status TINYINT NOT NULL DEFAULT 0 COMMENT 退款状态 0-无 1-申请中 2-已退款, total_amount BIGINT NOT NULL COMMENT 订单总金额, 单位分, discount_amount BIGINT NOT NULL DEFAULT 0 COMMENT 优惠金额, 单位分, pay_amount BIGINT NOT NULL COMMENT 实付金额, 单位分, goods_count INT NOT NULL DEFAULT 0 COMMENT 商品总件数, province_code INT UNSIGNED NOT NULL COMMENT 省份编码, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新时间, PRIMARY KEY (id), UNIQUE KEY uk_order_id (order_id), KEY idx_user_id (user_id), KEY idx_shop_id (shop_id), KEY idx_create_time (create_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT交易订单表;这个表结构里有几个值得复盘的点主键用 BIGINT为海量订单数据留足了空间用户ID、店铺ID用 BIGINT因为上游系统生成的就是雪花ID不能用 INT强行用 INT 会在接入阶段出现溢出状态用 TINYINT取值范围小节省空间配合注释展示清晰语义金额用 BIGINT 存“分”避免浮点误差同时为高额订单留出空间省份编码用 INT UNSIGNED因为编码本身是正数用无符号类型多出一倍的可表达空间这种“一看字段就知道业务边界”的表结构是值得推荐的设计风格。6.2 建表时需要反复问自己的几个问题每次设计表结构时我建议带着一套问题轮番过一遍可以有效避免大部分类型选型失误这个字段存的是什么业务值数值是否有界最大可能是多少未来三年到五年这个值有可能增长到什么量级这个字段是否要和另一张表的字段做 JOIN两边类型是否完全一致这个字段在应用层会被映射成什么类型是否有溢出风险这个字段会出现负数吗用 UNSIGNED 会不会给未来埋坑是否存在格式化展示的需求如果有是否应该放在应用层解决这套问题比任何现成的规则都管用因为你在真正问自己的过程中会更深入地理解业务边界。数据库字段类型的选择没有银弹永远是在具体业务约束下的权衡。6.3 现有的表还能优化吗如果你接手了一个老项目发现里面有大量可以优化空间不要贸然全局 ALTER TABLE。刚上线时听运维朋友讲过一句话改表一时爽锁表火葬场。MySQL 的 DDL 虽然支持在线 DDL但代价是可能产生临时文件、占用大量 IO大表可能拖垮主库。我的建议是分三步走第一步先对现有表做盘点统计每个整数类型字段的当前最大值、最小值、空值率、增长率第二步筛选出真正需要调整的字段优先处理有溢出风险的第三步在业务低峰期或用在线工具逐个变更变更前备份变更后对比前后数据比如一个日志表的 time_value 字段存的是毫秒时间戳当前用的是 INT但实际上数据量已经接近 20 亿毫秒。尽早改成 BIGINT 是唯一正确的选择拖得越久越难改。结尾个人经验与一段补充提醒在我自己维护过的项目里因为整数类型选错而导致的线上故障至少遇到过三次。一次是 INT 自增主键接近溢出一次是 BIGINT 字段映射到 Java Integer 导致数据错乱还有一次是状态字段塞进了超过 127 的值导致 TINYINT 报错。事后复盘的时候发现这些故障只要在建表阶段多想五分钟完全可以避免。所以最后分享一个我个人养成的习惯凡是新建表主键一律 BIGINT凡是状态、标志、类型类字段一律 TINYINT凡是计数、数量类字段先想想最大可能值再决定 INT 还是 BIGINT。数据库表结构是变更成本最高的代码一次设计失误后面要花十倍的运维成本去修补。你要是能从这篇内容里带走一句话我希望是这句话字段类型不只是“能不能放得下”的问题更是“将来能不能撑得住”的问题。
我在做后端开发的时候最常被新人问倒的问题之一就是建表的时候用户ID到底用 INT 还是 BIGINT一个状态字段用 TINYINT 会不会不够明明都是整数MySQL 为什么要分 TINYINT、INT、BIGINT 这么多种类说实话这些基础问题看起来简单但选错了代价很大——轻则白占存储空间重则字段溢出、数据写入失败线上事故就是这么来的。这篇东西我就把自己这些年对 MySQL 整数类型的理解和实操经验梳理一遍从存储原理讲到具体的业务选型再聊几个容易踩的坑。适合刚接触数据库设计的同学通读一遍也适合写过一阵子但没系统整理过类型体系的开发者用来查漏补缺。1. 整数类型的基础认知存储、范围与业务直觉1.1 字节数才是类型的本质MySQL 里整数类型最大的区别不在于“能存多大数”而在于“占多少字节”。TINYINT 占 1 个字节INT 占 4 个字节BIGINT 占 8 个字节。这背后是计算机存储的基本单位1 个字节等于 8 个比特位能表达 2 的 8 次方也就是 256 种组合。所以 TINYINT 理论上可以表示 0 到 255无符号或者 -128 到 127有符号它的取值范围直接由比特位数决定。同样地INT 用 32 个比特位BIGINT 用 64 个比特位。这些数字很多人在大学课本里见过但真正理解它的人不多——类型选型的本质就是在“够用”和“省空间”之间找平衡点。举一个直观的例子如果一个表有 1 亿行数据某个字段从 INT 改成 TINYINT每行省 3 个字节总共省下约 286 MB 的存储空间。如果这张表还有几个二级索引那节省的就不只是行数据本身还包括索引占用的空间。反过来如果一个字段用 TINYINT 但业务值可能会超过 127那就等着线上写数据时报 Out of range 错误吧。1.2 取值范围的计算方法看懂就够了我见过不少开发者记不住各类型的范围每次都去查手册。其实只要记住一个公式有符号范围负半轴是 -2^(n-1)正半轴是 2^(n-1)-1无符号范围是 0 到 2^n-1其中 n 是比特位数。TINYINT8 位有符号 -128 到 127无符号 0 到 255INT32 位有符号 -2147483648 到 2147483647无符号 0 到 4294967295BIGINT64 位有符号 -9223372036854775808 到 9223372036854775807无符号 0 到 18446744073709551615为什么正半轴要减 1因为 0 占了其中一个位置。这个细节很多人在计算时容易漏掉比如 INT 的正半轴很多口头描述说“21亿”精确值其实是 2147483647。我把这三类最常用的整数类型整理成一个速查对照表方便建表时直接瞟一眼类型字节数有符号范围无符号范围典型用途TINYINT1-128 ~ 1270 ~ 255状态码、开关、性别、删除标记SMALLINT2-32768 ~ 327670 ~ 65535小范围计数、枚举值扩展MEDIUMINT3-8388608 ~ 83886070 ~ 16777215中等长度计数INT4-2147483648 ~ 21474836470 ~ 4294967295常规ID、计数器、普通数值BIGINT8约 -9.22e18 ~ 9.22e180 ~ 约 1.84e19雪花ID、超大数据量主键、金额分顺带说一句SMALLINT 和 MEDIUMINT 也是很常用的只是标题里重点讲 TINYINT、INT、BIGINT 这三兄弟。实际工作中 SMALLINT 适合放枚举值扩展场景MEDIUMINT 相对冷门一些我曾经在一个数据量巨大的日志表里用它存储请求耗时毫秒级效果也很好。1.3 有符号还是无符号别想当然在 MySQL 中整数类型默认是有符号的SIGNED但你可以显式声明为无符号UNSIGNED。什么场景下用 UNSIGNED最常见的判断标准就是业务值是否可能出现负数。如果字段存的是“价格差额”可能出现负数必须用 SIGNED如果字段存的是“库存数量”“点击次数”“IP地址段”永远不会为负数用 UNSIGNED 可以在同等字节下把正数上限翻倍比如 TINYINT 有符号上限 127改成 UNSIGNED 后上限变成 255。INT UNSIGNED 的上限是 42.9 亿刚好是 INT 有符号上限的两倍这对于一些不能轻易用 BIGINT因为存储空间和索引宽度都更大的场景很有吸引力。但是我也要提醒如果某天业务需求变化原本非负的字段要支持负数那么 UNSIGNED 就会成为限制。我在实际项目里见过一个教训某个计数器字段用 INT UNSIGNED后来产品要做“余额增减”余额可能变成负数结果数据库层直接写不进去最后只能改字段类型加迁移脚本。所以无符号的选择要考虑未来业务边界不能只看当下。另外在 JOIN 关联时两个表的关联字段类型最好完全一致包括有符号无符号也必须一致。如果一张表是 INT UNSIGNED另一张是 INT SIGNEDMySQL 要做隐式转换往往会导致索引失效、全表扫描。这一点很多人写 join 语句时根本没注意以为是相同类型就万事大吉了。2. 别被 INT(11) 骗了显示宽度与存储大小无关2.1 括号里的数字到底有什么用很多从 Navicat 或旧版建表脚本里看到INT(11)的人会误以为 11 表示这个字段最多只能存 11 位数字。这是一个流传很广的误解必须纠正。INT(11)中的 11 是“显示宽度”display width它只在两个条件下有效果字段设置了 ZEROFILL零填充并且查询结果需要按固定宽度显示。它不限制存储范围——INT 不管写 INT(11) 还是 INT(3)取值范围都是完全一样的 21.47 亿上限。也就是说括号里的数字不影响你能存多少数据也不影响存储空间。比如一个字段定义为TINYINT(2) UNSIGNED ZEROFILL你插入一个 5查询出来显示为 05但实际存储值仍然是 5。这只是展示层面的补零效果。2.2 显示宽度的实际应用场景那 ZEROFILL 在什么场景下有用比较经典的是一个订单号场景要求编号固定 8 位不足 8 位前面补零。如果业务上允许用自增数字且不超过 99999999那么定义INT(8) UNSIGNED ZEROFILL就能在查询时自动显示成00001234。但我个人的建议是除非有很强的展示需求否则不要依赖数据库层的 ZEROFILL。原因有三个ZEROFILL 会影响存储和比较在 MySQL 中启用 ZEROFILL 的列会被隐式加上 UNSIGNED 属性这可能导致负数场景出问题展示格式化属于表现层逻辑应该由后端代码处理比如在 SQL 查询后用字符串补零函数或直接在接口层处理不同版本的 MySQL 对显示宽度的支持细节有差异比如 8.0 已经弃用了部分显示宽度语法后面维护容易踩坑2.3 新版本建表时怎么写最稳妥现在写 SQL 建表我推荐直接用不带括号或带标准宽度的写法。比如CREATE TABLE order_info ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 主键ID, order_no VARCHAR(32) NOT NULL COMMENT 业务订单号, status TINYINT NOT NULL DEFAULT 0 COMMENT 订单状态: 0待支付 1已支付 2已取消, user_id BIGINT NOT NULL COMMENT 用户ID, PRIMARY KEY (id), KEY idx_user_id (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单表;关于括号数字我的经验是既然不限制存储长度就没必要写得花里胡哨。MySQL 8.0 已经在逐步弱化整数显示宽度的语义建议新项目在定义表结构时就统一风格写出没有歧义的 DDL 脚本。3. 实战选型指南不同业务场景到底该选哪个3.1 主键字段从 INT 到 BIGINT 的抉择自增主键是所有 MySQL 表中最常见的整数应用。我见过无数张表用INT AUTO_INCREMENT一般业务下没问题但有个隐患INT 有符号上限 21.47 亿无符号也才 42.9 亿。看着很大但是对于日志流水、用户关系、交易记录这类高频插入的表达到这个量级并不是不可能。关键点在于INT 主键涨到上限后再插入数据就会主键溢出整张表不可写入。这个事故一旦发生扩容非常麻烦不光是改字段类型还要重建索引、处理缓存业务中断时间你根本预估不出来。所以我的建议是凡是主键直接上 BIGINT不要犹豫。有人觉得 BIGINT 比 INT 多 4 个字节存储和索引都变大但在绝大多数业务下这点空间换来的是几十年的增长余量非常划算。尤其是 MySQL InnoDB 引擎中二级索引都会包含主键列所以主键越大每个二级索引也会相应增大。可是相比于主键溢出的运维灾难多出来的存储开销完全可接受。执行 ALTER TABLE 修改主键类型时有个细节要提醒在线 DDL 虽然支持 MODIFY COLUMN但修改主键类型往往意味着重建表在亿级大表上执行时极可能锁表或产生巨大 IO 压力。我建议选择业务低峰期操作或者用 gh-ost 这类工具做在线变更并提前备份。3.2 状态类字段TINYINT 的好处比你想象的多应用层最常见的枚举字段订单状态、用户状态、逻辑删除标记、性别、消息是否已读。这类字段取值范围很小可能就 0 到 10 的几种状态用 TINYINT 是唯一的正解。为什么不用 INT原因很简单TINYINT 只占 1 字节INT 占 4 字节。一张订单表可能几千万行三个状态字段加起来每行省 9 字节整表省下几百 MB 的磁盘和内存缓冲池缓存行数据时同样受益。这段优化几乎是零成本的。另一个容易被忽略的点TINYINT 对代码规范有积极影响。因为它范围小你在写后端枚举转换时会下意识地去维护一个完整的映射表。如果字段是 INT可能有人就把魔法数字散落在代码里。虽然这不是数据库本身的问题但类型设计确实会影响团队的编码习惯。建议在枚举字段上加上注释把每个数字的含义写清楚例如status TINYINT NOT NULL DEFAULT 0 COMMENT 0-待支付 1-已支付 2-已退款 3-已关闭这样其他同事接手时不用去翻代码就能明白业务含义也避免了一个数字在不同表里代表不同含义的混乱。3.3 中频数值与计数器INT 的主场当数值范围超过 255、但又明显远小于 21 亿时INT 是最常见的选择。典型的场景包括文章的阅读数、商品的库存量、用户的积分余额、某个资源的总下载次数、消息队列里的重试次数等。这类字段的核心特点是值会增长可能到千万级甚至上亿但很少超过 21 亿。如果你预期极限值可能在 10 亿这个量级我建议认真评估一下是否应该用 BIGINT因为 INT 无符号上限是 42.9 亿而有符号上限才 21.47 亿。假设一个热门视频播放量能到 20 亿你用的是 INT SIGNED那就位于危险边缘了。还有一个容易忽略的点用 UPDATE 语句做自增时一旦值溢出语句会直接报错而不是自动封顶。比如UPDATE video SET play_count play_count 1 WHERE id 123;如果 play_count 已经接近 INT 上限这个更新就可能失败。所以计数器字段在预估波动大时宁可直接用 BIGINT省得后面再改表。3.4 超大数值与分布式IDBIGINT 的专属场景BIGINT 的典型应用场景包括雪花算法生成的分布式 ID、超大数据量的主键、需要精确存储的大整数、某些系统时间戳等。雪花 ID 是一个典型的必须用 BIGINT 的例子。雪花算法生成的结果通常是 64 位整数往往会超过 INT 的 42.9 亿上限如果建表时用 INT 去接数据直接溢出报错。我见过有人把所有表主键统一设计成 BIGINT就是为了给未来接入分布式 ID 留好余地。另外一个容易被忽略的场景是时间戳。某些系统设计里时间戳用毫秒级存储成一个整数比如 2025 年的毫秒时间戳大约是 1700000000000 这个量级远远超过 INT 的 21 亿。如果存到 INT 字段结果就是写入失败。所以当你在建表时看到“time_value”“ts”这类字段先确认它是秒级还是毫秒级再决定类型。4. 容易踩坑的细节类型转换、溢出与隐式陷阱4.1 条件查询里的字符串与整型隐式转换这是实战中出现频率最高的坑之一。假设某张表的user_id字段是 BIGINT你在代码里拼 SQL 时不小心传了一个字符串比如SELECT * FROM user WHERE user_id 123abc;MySQL 会把字符串转换成数字再比较。如果这个字符串不是纯数字转换时可能出现警告而且更严重的是如果字段本身是字符串类型而传入的是数字也可能会使索引失效。不过对于整型字段更多的问题出在另一侧——你把字符串类型的字段和数字比较就会导致字段上的索引失效。这些坑虽然不属于 TINYINT、INT、BIGINT 内部的问题但恰恰是整数类型使用中最常见的隐患。我建议所有写查询的同事都要保持字段类型和传入参数类型的一致性。尤其在 MyBatis 之类的框架里动态 SQL 容易因为参数类型没写对而触发隐式转换。出现慢查询时用 EXPLAIN 看一下 key 列和 rows 列如果明明建了索引却走了全表优先排查类型是否一致。4.2 数值溢出静默与报错的边界在 MySQL 的不同模式下数值溢出的表现不太一样。默认情况下如果给一个 TINYINT 字段插入 200MySQL 会在非严格模式下把值截断为 127 或 255并产生一个警告而不是报错。在严格模式sql_mode 中包含 STRICT_TRANS_TABLES下插入超出范围的值会直接报错。实际生产中我强烈建议开启严格模式默认的宽松模式会让数据悄悄变坏等到查数时才发现不对那时候已经很难追溯了。检查当前会话的 sql_mode 可以执行SELECT sql_mode;如果发现没有 STRICT_TRANS_TABLES可以加上。修改方式可以写在配置文件或会话中执行SET SESSION sql_mode STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION;注意这个修改只在当前会话有效持久化要改配置文件并重启实例。这也是一个我面对新环境时首先会检查的项目。4.3 整型与 DECIMAL、FLOAT 的边界意识有些人会在金额字段上用 BIGINT以“分”为单位存储整数金额这是一种常见的做法优点是不会出现浮点误差。但要注意金额计算如果涉及汇率换算结果可能是小数用 BIGINT 存储时要么四舍五入要么拆成两个字段。与此相对的不要用 FLOAT/DOUBLE 来存需要精确比较的数值会有精度问题。如果确实要用小数DECIMAL 才是合适的选择。这些内容虽然不是整型本身但选型时要把它们放在同一张决策表里考虑。我在一个项目中曾见过这样的设计用户余额用 DECIMAL(10,2)积分用 INT折扣用 FLOAT。结果折扣计算时因为 FLOAT 精度问题导致积分数值出现偏差排查了很久。总结一句话需要精确十进制运算时选 DECIMAL需要连续数值计算时考虑 DOUBLE但无论如何别把金额、积分这类关键业务数值让给浮点类型。4.4 综合性避坑清单把上面提到的坑整理成一张速查表方便建表评审和排查问题时对照常见问题典型表现解决办法整型字段溢出insert/update 报 Out of range value预估数据量直接上 BIGINT关联字段类型不一致JOIN 慢、索引失效统一两表字段类型和有符号属性整数类型当字符串比较查询结果异常或索引失效保持参数类型与字段类型一致状态字段用 INT存储空间浪费、枚举易乱无脑用 TINYINT 就好显示宽度误用误以为限制长度抛弃 INT(N) 思维8.0 后更应简化写法自增主键用 INT数据量大后溢出风险新表主键全部用 BIGINT非严格模式截断数据悄悄变小开启 STRICT_TRANS_TABLES5. 代码层的类型映射从数据库到应用的一一对应5.1 各语言里 TINYINT、INT、BIGINT 对应的类型建表选型只是第一步应用层读取数据时要选用匹配的数据类型。这里如果映射错了同样会踩坑。在 Java 中TINYINT 映射为 Byte 或 ShortINT 映射为 IntegerBIGINT 映射为 Long。如果数据库字段是 BIGINT但你在实体类里用 Integer 接收查询结果超过 21 亿就可能直接被 MyBatis 转成负数或报转换异常。另外使用 ResultSet.getInt() 读取 BIGINT 字段也可能溢出建议读取大整数时使用 getLong()。在 Go 中TINYINT 对应 int8但为保险起见通常扫描到 int 也没问题INT 对应 int32 或 intBIGINT 对应 int64。如果你在 GORM 里用 int 接 BIGINT 字段在 32 位系统上会溢出。Python 的 int 是变长的反而没有这些问题但 ORM 内部仍可能对长度有约束。无论什么语言原则很简单应用层的数值类型范围一定要能覆盖数据库字段的取值范围。5.2 自增主键与 ORM 的配合有的团队会在后端代码里自己生成主键而不是依赖数据库自增。常见的做法是用雪花算法生成一个 BIGINT 主键这种 ID 因为不是一个连续的递增序列对 InnoDB 的索引页写入会产生一定随机性。所以很多系统会采用“BIGINT 自增主键 业务ID唯一索引”的设计兼顾写入性能与业务查询需求。如果你用的是 ORM 框架插入后需要回填自增主键。在 MyBatis 中使用useGeneratedKeystrue可以拿到自增 IDJPA 则通过GeneratedValue配合GenerationType.IDENTITY。这些场景下主键类型要和数据库定义完全一致才能避免精度损失。比如数据库用 BIGINTJava 实体用 Long那么 MyBatis/JPA 回填的类型也要是 Long。5.3 数据同步与跨库对比时不要丢精度BIGINT 的最大值是 9223372036854775807这个数字有 19 位而 JavaScript 的 Number 安全整数上限是 900719925474099116 位。所以如果你在前端页面直接展示后端传过来的 BIGINT 主键就可能发生精度丢失。比如某个 ID 是 17612345678901234567前端拿到后变成 17612345678901234000再往后端传就完全对不上了。这个问题在电商、社交等场景里很常见解决办法有两个一是把 BIGINT 主键序列化成字符串传给前端二是干脆在应用中额外生成一个 String 类型的业务编号比如订单号作为前端交互的主键。我个人更推荐后者因为字符串业务主键更灵活而且可以内置业务规则比如日期加序号。另外一个场景是跨数据库同步。从 MySQL 同步到其他数据库或数据仓库时如果目标库没有 BIGINT 类型只能把这类字段定义为 DECIMAL 或字符串否则就会丢精度。数据同步时最好加个校验环节对比源和目标的最大值、最小值、总数早发现问题早处理。6. 实际表结构案例与设计思路复盘6.1 一个完整的订单表设计案例与其零散地讲不如直接给一个案例。假设我们设计一张电商订单表核心字段如下CREATE TABLE trade_order ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 自增主键, order_id VARCHAR(32) NOT NULL COMMENT 业务订单号(对前端展示), user_id BIGINT NOT NULL COMMENT 用户ID(雪花ID), shop_id BIGINT NOT NULL COMMENT 店铺ID(雪花ID), status TINYINT NOT NULL DEFAULT 0 COMMENT 订单状态 0-待支付 1-已支付 2-已发货 3-已完成 4-已取消, refund_status TINYINT NOT NULL DEFAULT 0 COMMENT 退款状态 0-无 1-申请中 2-已退款, total_amount BIGINT NOT NULL COMMENT 订单总金额, 单位分, discount_amount BIGINT NOT NULL DEFAULT 0 COMMENT 优惠金额, 单位分, pay_amount BIGINT NOT NULL COMMENT 实付金额, 单位分, goods_count INT NOT NULL DEFAULT 0 COMMENT 商品总件数, province_code INT UNSIGNED NOT NULL COMMENT 省份编码, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新时间, PRIMARY KEY (id), UNIQUE KEY uk_order_id (order_id), KEY idx_user_id (user_id), KEY idx_shop_id (shop_id), KEY idx_create_time (create_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT交易订单表;这个表结构里有几个值得复盘的点主键用 BIGINT为海量订单数据留足了空间用户ID、店铺ID用 BIGINT因为上游系统生成的就是雪花ID不能用 INT强行用 INT 会在接入阶段出现溢出状态用 TINYINT取值范围小节省空间配合注释展示清晰语义金额用 BIGINT 存“分”避免浮点误差同时为高额订单留出空间省份编码用 INT UNSIGNED因为编码本身是正数用无符号类型多出一倍的可表达空间这种“一看字段就知道业务边界”的表结构是值得推荐的设计风格。6.2 建表时需要反复问自己的几个问题每次设计表结构时我建议带着一套问题轮番过一遍可以有效避免大部分类型选型失误这个字段存的是什么业务值数值是否有界最大可能是多少未来三年到五年这个值有可能增长到什么量级这个字段是否要和另一张表的字段做 JOIN两边类型是否完全一致这个字段在应用层会被映射成什么类型是否有溢出风险这个字段会出现负数吗用 UNSIGNED 会不会给未来埋坑是否存在格式化展示的需求如果有是否应该放在应用层解决这套问题比任何现成的规则都管用因为你在真正问自己的过程中会更深入地理解业务边界。数据库字段类型的选择没有银弹永远是在具体业务约束下的权衡。6.3 现有的表还能优化吗如果你接手了一个老项目发现里面有大量可以优化空间不要贸然全局 ALTER TABLE。刚上线时听运维朋友讲过一句话改表一时爽锁表火葬场。MySQL 的 DDL 虽然支持在线 DDL但代价是可能产生临时文件、占用大量 IO大表可能拖垮主库。我的建议是分三步走第一步先对现有表做盘点统计每个整数类型字段的当前最大值、最小值、空值率、增长率第二步筛选出真正需要调整的字段优先处理有溢出风险的第三步在业务低峰期或用在线工具逐个变更变更前备份变更后对比前后数据比如一个日志表的 time_value 字段存的是毫秒时间戳当前用的是 INT但实际上数据量已经接近 20 亿毫秒。尽早改成 BIGINT 是唯一正确的选择拖得越久越难改。结尾个人经验与一段补充提醒在我自己维护过的项目里因为整数类型选错而导致的线上故障至少遇到过三次。一次是 INT 自增主键接近溢出一次是 BIGINT 字段映射到 Java Integer 导致数据错乱还有一次是状态字段塞进了超过 127 的值导致 TINYINT 报错。事后复盘的时候发现这些故障只要在建表阶段多想五分钟完全可以避免。所以最后分享一个我个人养成的习惯凡是新建表主键一律 BIGINT凡是状态、标志、类型类字段一律 TINYINT凡是计数、数量类字段先想想最大可能值再决定 INT 还是 BIGINT。数据库表结构是变更成本最高的代码一次设计失误后面要花十倍的运维成本去修补。你要是能从这篇内容里带走一句话我希望是这句话字段类型不只是“能不能放得下”的问题更是“将来能不能撑得住”的问题。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
