主键应按未来5–8年数据规模选择：未超INT上限（有符号21亿/无符号42亿）用INT UNSIGNED，否则直接BIGINT；溢出前预警信号包括MAX(id)超15亿、日增超百万记录、需对接JS或分布式ID等场景。
主键用 INT 还是 BIGINT，不是“哪个更好”，而是“当前数据规模和未来 5–8 年增长是否可能突破 INT 上限”——没到阈值就用 INT UNSIGNED，到了或不确定就直接上 BIGINT。
主键溢出前最后的警告信号是什么
MySQL 插入时抛出 Out of range value for column 'id' at row 1 就是硬性崩溃点，但别等它发生。真正该警惕的是：
-
SELECT MAX(id) FROM users返回值 > 15 亿（有符号INT安全余量）或 > 35 亿（INT UNSIGNED安全余量） - 日均新增主键记录 > 100 万，且业务处于高速增长期（比如新 App 用户月增 20%+）
- 主键要参与分库分表、导出到数仓、或对接外部系统（如 Kafka 消息体里传 ID），而对方系统对整数精度有隐式限制（例如 JS
Number.MAX_SAFE_INTEGER = 9007199254740991，远小于BIGINT上限，但大于INT）
INT 和 BIGINT 存储字节差异带来的真实开销
每行多占 4 字节，听起来微不足道，但在高基数场景下会层层放大：
- 单表 1 亿行 → 多占约 400MB 磁盘；10 亿行 → 多占约 4GB；这还不含二级索引（每个含主键的二级索引项也跟着涨 4 字节）
- InnoDB 的页默认 16KB，
INT主键能让一页塞更多记录/索引项，B+ 树层级更浅，理论上单次主键查询少一次磁盘 I/O（实际差异在纳秒级，但百亿级表里会累积） - 如果主键是联合索引的最左前缀（比如
(status, id)），BIGINT会让这个索引体积显著膨胀，降低缓冲池命中率 - 应用层 ORM（如 MyBatis、Django ORM）映射字段类型不匹配时，可能静默截断或报类型转换异常，尤其 Java 的
intvslong、Go 的int32vsint64
为什么现在越来越多项目默认用 BIGINT 自增主键
不是因为性能更好，而是规避演进成本。关键现实因素包括：
- 时间戳毫秒值（如
created_at_ms）已普遍作为逻辑主键或排序依据，它在 2038 年后必然超INT，若主键和时间戳类型不一致，关联查询易出错 - 分布式 ID（如 Snowflake）输出是 64 位整数，必须用
BIGINT接收，混用INT会导致高位丢失 - 云数据库（如阿里云 PolarDB、腾讯云 TDSQL）默认推荐
BIGINT，因分片键、全局索引等底层机制对宽度更宽容 - 从
INT升级到BIGINT是 DDL 变更：MySQL 5.6+ 支持ALGORITHM=INPLACE，但仍需元数据锁（MDL），高峰期可能卡住写入；PostgreSQL 必须重写表
真正容易被忽略的点是外键约束——子表字段类型必须和主表主键**完全一致**，包括是否有 UNSIGNED。比如主表用 INT UNSIGNED，子表写了 INT，MySQL 不报错但会隐式转换，导致索引失效或查询结果异常。这种细节在跨团队协作或历史表迁移时最容易翻车。
