ZEROFILL 使整数列自动转为 UNSIGNED 并左补零至显示宽度（如 INT(5) ZEROFILL 存 42 得 '00042'），但该宽度在 MySQL 8.0.17+ 已失效，且返回字符串类型、隐式截断超限值、耦合格式与数据语义。
MySQL 中 INT 的 ZEROFILL 实际效果是什么
zerofill 不是格式化显示开关，而是列定义的一部分，它会自动给数值左侧补零到字段宽度，并隐式启用 unsigned。比如 int(5) zerofill 存 42，查出来就是 00042；但这个“5”不是最小宽度保证，只是显示宽度提示（mysql 8.0.17+ 已弃用该提示作用）。
常见错误现象：SELECT 返回字符串类型值（实际是带前导零的字符串），且无法在应用层靠类型推断还原为数字；插入超宽数字时会被截断但不报错（因 UNSIGNED 限制 + 隐式转换）。
-
ZEROFILL只对整数类型有效（TINYINT/SMALLINT/…/BIGINT），DECIMAL或字符串类型不能用 - 一旦加了
ZEROFILL，该列自动变成UNSIGNED，负数插入会转成 0 或报错（取决于 SQL 模式） - MySQL 8.0.17 起，
INT(5)中的(5)完全被忽略，仅ZEROFILL还起作用；低版本中(5)也仅影响显示，不影响存储或校验
为什么不该依赖 ZEROFILL 做前端展示
它把格式逻辑耦合进了表结构，导致数据语义污染：同一数值在不同客户端可能显示不一致（如命令行 MySQL、PHP PDO、某些 ORM 会剥离前导零），而且迁移或导出时容易丢失格式。
使用场景应严格限定在遗留系统兼容或极简 CLI 报表输出；新项目一律改用应用层或 SQL 层格式化。
- PHP 中用
sprintf('%05d', $id)更可控，且不依赖数据库行为 - SQL 查询中可用
LPAD(CAST(id AS CHAR), 5, '0')，兼容所有整型，也不触发UNSIGNED强制 - ORM 如 Laravel Eloquent 可在访问器（accessor）里统一处理，避免每处都写格式逻辑
ZEROFILL 在 ALTER TABLE 时的坑
给已有列加 ZEROFILL 是 DDL 操作，会锁表（尤其大表），且触发隐式类型变更：原 INT 列会变成 INT UNSIGNED ZEROFILL，可能导致应用写入负数失败或静默转 0。
错误现象包括：应用日志出现 “Out of range value for column”，但 INSERT 语句没报错（因 SQL mode 允许），查出来的值却是 0 或最大无符号值。
- 执行前必须确认该列当前无负数数据，且所有业务代码已适配
UNSIGNED - 不能单独加
ZEROFILL，必须连同UNSIGNED显式写出，例如：ALTER TABLE t MODIFY id INT UNSIGNED ZEROFILL - 如果只想改显示效果，直接用视图或查询时
LPAD更安全，避免改表结构
替代方案：什么时候该用 CHAR 或 VARCHAR 存零填充编号
当编号本质是编码（如订单号 ORD0000123），而非可计算数值时，CHAR 更合适——它明确表达“这是带格式的标识符”，不会误导开发者做算术操作。
性能影响很小（定长 CHAR(10) 比变长 VARCHAR(10) 略快，但现代 MySQL 差异可忽略），关键是语义清晰、迁移友好、API 输出稳定。
- 生成时用应用逻辑或数据库序列 + 格式化函数，如 MySQL 的
CONCAT('ORD', LPAD(nextval(), 7, '0')) - 索引效率不受影响，
CHAR和INT在等值查询上性能接近 - 避免用
ZEROFILL冒充编码——它无法支持字母前缀、分隔符、多级结构等真实业务需求
真正麻烦的不是怎么加零，而是零该由谁负责、何时生成、是否参与计算。一旦把它塞进列定义，就等于把格式决策权交给了建表那一刻的自己，而那时候往往还没想清楚业务边界。
