MySQL 5.7 升级 8.0 整数类型显示变化深度解析：INT (num) 的本质

一、升级引发的显示异常：从 INT (10) 到 INT 的蜕变

在 MySQL 从 5.7 版本升级至 8.0 的过程中，不少用户遇到表结构显示变更问题：原表中定义为INT(10)的字段，升级后在SHOW CREATE TABLE输出中变为INT。以某客户案例为例，升级前表结构为：

CREATE TABLE t2 (
  id1 INT(4) UNSIGNED,
  id2 INT(10) UNSIGNED
) ENGINE=InnoDB;

 

升级至 8.0.35 后变为：

 

CREATE TABLE t2 (
  id1 INT UNSIGNED,
  id2 INT UNSIGNED
) ENGINE=InnoDB;

表面上看字段定义简化，但数据存储与查询结果均未受影响，这背后涉及 MySQL 整数类型的显示规则与版本差异。

二、INT (num) 的真实语义：显示宽度 vs 数据范围

1. 语法解析：被误解的 "数据范围限制"

MySQL 中INT(num)的num并非用于限制数据范围，而是显示宽度，需配合ZEROFILL属性使用才会生效。例如：

 

CREATE TABLE t1 (
  id INT(4) UNSIGNED ZEROFILL -- 显示宽度4，不足补0
);
INSERT INTO t1 VALUES (1); -- 存储为1，查询显示为0001

 

单独使用INT(num)时，num会被忽略，字段实际等价于INT。这与CHAR(num)限制字符长度的机制完全不同，是导致用户困惑的核心原因。

2. 存储本质：类型范围由字节数决定

MySQL 整数类型的取值范围由存储字节数决定，与显示宽度无关：

类型	字节数	有符号范围	无符号范围
TINYINT	1	-128 ~ 127	0 ~ 255
INT	4	-2147483648 ~ 2147483647	0 ~ 4294967295
BIGINT	8	-9223372036854775808 ~ 9223372036854775807	0 ~ 18446744073709551615

即使定义为INT(10)，其存储范围仍由 4 字节决定，无法插入超过2147483647（有符号）或4294967295（无符号）的值。

三、版本差异：5.7 与 8.0 的显示规则演变

1. MySQL 5.7 的默认显示

• 无ZEROFILL时，INT默认显示为INT(11)（兼容旧版语法）。
• 有ZEROFILL时，显示为INT(num)，其中num为定义的显示宽度。

2. MySQL 8.0 的优化逻辑

• 移除无意义的默认显示宽度，直接显示为INT，仅在存在ZEROFILL时保留num。
• 例如：

  -- 5.7显示
  CREATE TABLE t1 (id INT); -- 显示为INT(11)
  CREATE TABLE t2 (id INT(10) ZEROFILL); -- 显示为INT(10) ZEROFILL
  
  -- 8.0显示
  CREATE TABLE t1 (id INT); -- 显示为INT
  CREATE TABLE t2 (id INT(10) ZEROFILL); -- 显示为INT(10) ZEROFILL
  

   

这种变化旨在简化元数据显示，避免用户误解num与数据范围的关系。

四、升级影响评估与应对策略

1. 兼容性评估

• 数据层面：升级前后数据存储、查询结果完全一致，无精度丢失或范围变化。
• 元数据层面：仅SHOW CREATE TABLE输出变化，DDL 语句需注意兼容性（如应用程序依赖表结构中的INT(num)字符串）。

2. 应对建议

（1）检查 ZEROFILL 使用场景

若业务依赖ZEROFILL的补零显示，升级后表结构会保留INT(num) ZEROFILL定义，无需额外处理。例如：

 

-- 升级前
CREATE TABLE code (
  no INT(6) UNSIGNED ZEROFILL -- 存储1显示为000001
);

-- 升级后结构不变，功能正常

 

（2）应用程序适配

若应用通过解析表结构中的INT(num)判断字段属性（如 ORM 框架），需修改逻辑：

• 改用数据类型（如INT）而非显示宽度判断字段类型。
• 通过INFORMATION_SCHEMA.COLUMNS获取真实数据类型：

  SELECT DATA_TYPE, NUMERIC_PRECISION, COLUMN_TYPE
  FROM INFORMATION_SCHEMA.COLUMNS
  WHERE TABLE_NAME = 't2';
  

   

（3）避免无意义的 INT (num) 定义

在新业务中，除非需要ZEROFILL，否则直接使用INT类型，保持表结构简洁。例如：

-- 推荐写法
CREATE TABLE user (
  age INT UNSIGNED -- 无需指定显示宽度
);

 

五、最佳实践：升级前的准备与验证

1. 兼容性测试
   在测试环境模拟升级，对比升级前后SHOW CREATE TABLE输出，检查应用对表结构的解析逻辑。
2. 数据验证
   执行全量数据校验（如pt-table-checksum），确保升级后数据一致性。
3. 文档更新
   在技术文档中明确字段定义规则，避免后续维护时对INT(num)的误解。

六、总结：理解本质，从容应对版本变迁

MySQL 5.7 升级 8.0 后的 INT 显示变化，本质是版本迭代中对语法糖的优化 —— 剥离无实际意义的显示宽度，回归数据类型的本质定义。对于业务而言，只需关注是否使用ZEROFILL场景，无需担心数据存储与功能异常。这一案例也提醒我们：在数据库设计中，应优先理解字段属性的底层逻辑，避免依赖表面语法导致的兼容性风险。通过合理的测试与适配，完全可以平滑过渡版本升级，充分享受 MySQL 8.0 的新特性与性能优势。