17370845950

选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 存储（会丢失信息或引入冲突）