选INT还是BIGINT取决于数据范围和存储开销，需按业务增长预留30%~50%余量：INT适用中小系统（上限21亿），超大规模、时间戳（2038年后）、高频计数等场景必须用BIGINT；升级需考虑DDL阻塞与生态兼容。
选 INT 还是 BIGINT，关键看数据范围和存储开销，不是越大越好。
数据范围决定是否必须用 BIGINT
INT（通常为 4 字节有符号整数）支持范围是 -2,147,483,648 到 2,147,483,647；BIGINT（8 字节）支持 -9,223,372,036,854,775,808 到 9,223,372,036,854,775,807。如果主键是自增 ID，且预计总量会超过 21 亿条，比如日志表、订单流水、用户行为埋点等高频写入场景，就必须用 BIGINT，否则会溢出报错或回绕。
- 用户表 ID：中小系统用
INT足够；超大规模平台（如千万日活+）建议起步就用BIGINT - 时间戳毫秒值：1970 年起的毫秒数在 2038 年后将超过
INT上限，需用BIGINT - 计数类字段（如点击量、播放量）：若单条记录可能超 21 亿，直接上
BIGINT
存储与性能差异真实存在但常被高估
每行多占 4 字节，在百万级表中增加约 0.4MB 存储；在十亿级大表中则多出约 4GB。内存占用、缓冲区效率、网络传输量也会随之略升。索引方面，BIGINT 索引页能存的键值更少，可能导致 B+ 树层级略深，查询时 I/O 次数微增 —— 但现代硬件下，单次查询差异通常在纳秒到微秒级，业务层几乎不可感。
- 联合索引中含
BIGINT字段，会使索引体积变大，影响缓存命中率 - 排序、分组、连接操作涉及
BIGINT时，CPU 计算开销略高，但瓶颈往往在磁盘或网络 - 除非 QPS 极高（如 >10 万/秒）且字段频繁参与计算，否则不必为这点差异提前过度优化
兼容性与演进成本容易被忽略
从 INT 升级到 BIGINT 是 DDL 阻塞操作，MySQL 5.6+ 支持在线 DDL，但仍需锁表短时间；PostgreSQL 需重写表。如果业务已上线多年，主键类型变更还牵扯应用层 ORM 映射、接口协议、前端展示逻辑（比如 JS Number 最大安全整数是 2⁵³−1，超此范围需用字符串传 BIGINT ID），风险不小。
- 新项目建议按预估上限选型，避免后期迁移
- 已有
INT表接近阈值（如 ID 达到 15 亿），应尽早规划升级，别等插入失败才处理 - 外键关联时，主表和子表字段类型必须严格一致，混用会报错或隐式转换失败
其他常见误区提醒
有人认为 “反正磁盘便宜，一律用 BIGINT 更省心”，这忽略了索引膨胀和生态适配问题；也有人坚持 “能用 INT 绝不用 BIGINT”，却在用户 ID 字段上硬扛，结果两年后被迫停服做数据迁移。理性做法是：以业务生命周期和增长模型为依据，留 30%~50% 余量，再选最紧凑且够用的类型。
-
TINYINT、SMALLINT、MEDIUMINT同理适用“够用即止”原则 - 无符号（
UNSIGNED）可让INT上限翻倍到 42 亿，适合只存正数的场景（如状态码、非负计数） - UUID 或雪花 ID 等分布式 ID 一般存为
CHAR(36)或BINARY(16)，不推荐转成BIGINT存储（会丢失信息或引入冲突）
