int固定占4字节，bigint固定占8字节；括号内数字仅为显示宽度，不影响存储，且mysql 8.0+已将其标记为弃用；选错类型会导致存储、索引及性能隐性成本显著上升。

INT 和 BIGINT 的字节占用直接决定存储差异

根本原因就一条：INT 固定占 4 字节，BIGINT 固定占 8 字节——这不是配置项或可调参数，是 MySQL 内核硬编码的存储规格。CPU 寄存器一次读写 4 字节（32 位）很自然，但要安全存下超过 2147483647 的数，就必须扩展到 8 字节（64 位）空间，否则高位数据直接被截断。

括号里的数字比如 INT(11) 不影响实际存储

很多人看到 INT(11) 或 BIGINT(20) 就以为括号里是“长度”或“字节数”，其实它只是 显示宽度提示，仅在配合 ZEROFILL 时起作用，对磁盘占用、内存消耗、索引大小完全没影响。无论你写 INT(1) 还是 INT(100)，该列始终占 4 字节。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

• INT(11) 存 5，默认显示为 5；加了 ZEROFILL 才会变成 00000000005
• BIGINT(20) 存 9223372036854775807，显示刚好 19 位，不补零
• MySQL 8.0+ 已明确标记这种语法为 deprecated，未来可能彻底移除

选错类型会导致隐性成本飙升

表面看只是多占 4 字节，但在高并发、大数据量场景下，这差异会层层放大：

• 每行多 4 字节 → 表体积翻倍（尤其当主键是 BIGINT 而业务 ID 永远 时）
• 二级索引中主键值要重复存储 → BIGINT 主键会让所有二级索引变宽，缓存命中率下降
• JOIN 或排序临时表使用磁盘临时表概率上升 → BIGINT 列让 tmp_table_size 更容易击穿
• 复制日志（binlog）体积增大 → 网络传输和备库回放延迟增加

什么时候必须用 BIGINT

不是“将来可能大”，而是当前或可预见增长路径上，ID 或计数值会撞上 INT 上限（2147483647）：

• 高频写入的订单/日志/埋点表，日增 > 100 万条，且保留周期 > 2 年
• 分布式系统用雪花算法（Snowflake）生成 ID，其时间戳 + 机器 ID + 序列组合后天然超 INT 范围
• 金融类累计字段（如总流水、总积分），单位是“分”，数值轻易破亿
• 已有表用了 AUTO_INCREMENT 且当前值已 > 2147483600，再插入就会报 ERROR 1062 (23000): Duplicate entry '2147483647' for key 'PRIMARY'

真正容易被忽略的是：**索引宽度膨胀比单行存储更伤性能**。一个 BIGINT 主键会让所有二级索引多存 4 字节 × 行数，而这个代价在建表时几乎没人测算。