int(1)和int(10)存储空间、取值范围完全相同，括号内数字仅影响ZEROFILL下的显示宽度，不约束数值大小；ORM或客户端可能读取该值做UI提示，但MySQL自身不强制限制；MySQL 8.0+已将其标记为弃用。
int(1) 和 int(10) 的存储空间完全一样
它们都占用 4 字节，有符号范围都是 -2147483648 到 2147483647，无符号是 0 到 4294967295。括号里的数字 1 或 10 不影响磁盘占用、内存使用、索引大小，也不改变你能存进去的数值上限或下限。
常见错误现象：建表时写 INT(1) 以为能“节省空间”或“限制只能输个位数”，结果插入 123456789 依然成功——因为根本没限制作用。
真正决定存储能力的是类型本身（INT、TINYINT、BIGINT），不是括号里的数字。
显示宽度只在 ZEROFILL 场景下可见
INT(1) 和 INT(10) 的区别，仅在配合 ZEROFILL 使用时才体现为输出格式差异：
-
INT(1) ZEROFILL→ 值7显示为0000000007（注意：实际显示位数是 10，不是 1；MySQL 会按INT默认显示宽度 11 补零，除非显式指定更小值且生效） -
INT(10) ZEROFILL→ 值7显示为0000000007（和上面一样，因为 MySQL 对INT类型的最小有效显示宽度其实是 10～11） - 不加
ZEROFILL时，SELECT返回的值就是纯数字，INT(1)和INT(10)完全无法区分
关键点：ZEROFILL 是开关，括号数字是目标宽度，但 MySQL 实际补零逻辑有默认兜底（比如 INT 默认按 11 位处理），所以 INT(1) ZEROFILL 并不会真的只显示 1 位——它仍会补到至少 10 位以上，取决于底层实现。
ORM 和客户端工具可能读取显示宽度
部分老版本 ORM（如早期 Django、SQLAlchemy）或图形化客户端（Navicat、DBeaver）在生成表单、校验前端输入长度、或自动生成代码时，会读取 INFORMATION_SCHEMA.COLUMNS.COLUMN_TYPE 中的显示宽度字段（如 int(10)），并据此做 UI 提示或长度限制。
但这属于应用层行为，不是 MySQL 自身强制约束。例如：
- Django 的
IntegerField不关心括号数字，但某些模板插件可能读取它来渲染 input 的maxlength - PHP PDO 获取列元数据时，
PDO::ATTR_COLUMN_COUNT不暴露显示宽度，但getColumnMeta()可能返回mysql:display_width字段（取决于驱动版本） - MySQL 8.0+ 已在文档中明确标注该属性“deprecated”，未来可能移除
别用 int(n) 做业务语义表达
有人把 status INT(1) 当作“只存 0/1”的暗示，或把 order_no INT(8) ZEROFILL 当作订单号规范——这容易埋坑：
-
status应该用TINYINT(1)+ 注释，或更清晰的ENUM('pending','done')/BOOLEAN（MySQL 中BOOLEAN是TINYINT(1)别名） -
order_no若真需固定 8 位零填充，ZEROFILL 在高并发插入时可能因隐式类型转换引发间隙锁争用；更稳妥的是应用层格式化或改用VARCHAR(8)存储已格式化字符串 -
INT(1)在 DDL 脚本里看起来像布尔，但其他开发者或 DBA 看到INT(10)可能误判字段用途，造成维护歧义
真正需要零填充的编号场景极少，而一旦用了 ZEROFILL，后续去 ZEROFILL 会触发全表重建（ALTER TABLE 重写数据），这个成本常被忽略。
