INT溢出时会报ERROR 1062重复主键错误，因自增计数器卡死反复重用最大值；BIGINT虽每行多占4字节，但相较停机迁移成本几乎可忽略，新项目直接选用是性价比最高的风控手段。
INT 和 BIGINT 的核心区别不是“能不能用”，而是“在什么规模下会出事”——INT 自增主键在数据量超 21 亿后必然溢出，而 BIGINT 在绝大多数业务生命周期内不会耗尽。
INT 溢出时会发生什么？
当 INT 主键走到 2147483647（有符号最大值）后继续插入，MySQL 默认行为是报错：ERROR 1062 (23000): Duplicate entry '2147483647' for key 'PRIMARY'。这不是偶然冲突，而是自增计数器卡死、反复尝试重用最大值导致的唯一键冲突。
- 如果表定义为
INT UNSIGNED，上限升至4294967295，但溢出后同样卡住或转为 0（取决于sql_mode是否含NO_AUTO_VALUE_ON_ZERO） - 线上服务一旦触发，写入直接失败，错误日志刷屏，恢复需人工干预（如
ALTER TABLE ... AUTO_INCREMENT = N），且无法自动跳过已用 ID - 溢出前无预警，监控通常只看 QPS 或慢查询，极少有人对「自增值接近上限」做告警
BIGINT 真的浪费存储吗？
每行多占 4 字节，听起来像小事，但叠加索引、JOIN、排序缓冲区后，实际影响远超表面计算。
-
INT主键 + 二级索引（如user_id）：索引 B+ 树节点里存的是INT值，每条索引记录省 4 字节；但主键本身是聚簇索引，BIGINT会让整张表的磁盘和内存占用上升约 1%~3%（实测百万行差异在 MB 级） - 真正吃资源的是关联查询：
JOIN时两表主键比对、临时表排序、JSON 序列化返回——这些过程都按实际字节数搬运，BIGINT多传的 4 字节会放大到网络、CPU 缓存、GC 压力上 - 但比起停机迁移成本（
ALTER TABLE百万级表锁表数小时），这点开销几乎可忽略；新项目直接选BIGINT是性价比最高的风控手段
什么时候可以放心用 INT？
不是“不能用”，而是必须满足三个硬条件：
- 业务明确限定总量：比如设备唯一码表，硬件出厂编号池仅 5000 万，且永不扩容
- 主键非自增：用 UUID、雪花 ID 或业务编码（如
'ORD-20260810-00001'），此时INT只作状态码、类型标识等小范围枚举字段 - 有成熟兜底方案：已实现自增溢出自动切换分库分表逻辑，或能秒级执行
ALTER TABLE ... MODIFY id BIGINT（需 MySQL 5.7+ 并开启ALGORITHM=INPLACE）
但要注意：ALTER TABLE 把 INT 改成 BIGINT 是 DDL 操作，即使支持原地修改，也会阻塞写入——别等报警才想起这事。
建表时漏写 UNSIGNED 会怎样？
很多人只记得换 BIGINT，却忽略符号位。默认 INT 和 BIGINT 都是有符号的，白白损失一半容量。
-
INT有符号上限是2147483647，无符号是4294967295；BIGINT从9223372036854775807提升到18446744073709551615 - 用户 ID、订单号、时间戳毫秒值这类纯正整数，一律加
UNSIGNED——它不改变存储结构，也不影响性能，只是把负数空间让渡给正数 - ORM 框架（如 Laravel Eloquent、MyBatis）生成的 migration 若没显式声明
unsigned()，默认就是有符号，上线前务必检查 SQL DDL
最常被忽略的不是字节大小，而是符号位是否启用——它让可用 ID 数量直接翻倍，且零成本。
