唉，前几天刚好在公司茶水间碰到我们运维小王，他跟我吐槽，说他们有个老系统快上线十年了，最近业务激增，数据库里的那个自增ID，眼看就要撞上 int 最大值了。小王特别头疼，跑过来问我，哥，面试有个经典问题：“MySQL 自增ID超过int最大值咋办？”他怕到时候生产环境直接翻车，被老板逮住就凉了。
其实这个场景真的不是啥小概率，你看国内很多老项目，都喜欢表主键用 int 类型，MySQL 里的自增主键 AUTO_INCREMENT 默认类型也是 int(11)，最大也就21亿多点（准确说是 2147483647），流量上来几年真够呛。
我当时正在泡茶，手上一杯铁观音，还差点没拿稳。想了一下就跟他说，你要真等撞线，业务那边新单插不进去了，SQL 报错啥的，整个服务都挂掉，出事基本没法挽救，用户体验直接负分。你说是不是，所以提前预警最重要。
聊到解决方案，其实最常见的就是把自增主键的类型从 int 升级到 bigint，因为 bigint 最大可以到 9223372036854775807，真够一般公司用一辈子的，别说你们公司，马老板的业务也够撑很久。
不过实际操作，怎么升？你直接改表结构肯定不现实啊，有些几千万、上亿条数据，alter table 一跑就是几小时，搞不好线上直接锁表，业务全卡死，这锅你背不动。所以得分几步走：
先给表加个新字段，比如叫 id_bigint，类型是 bigint unsigned，千万记得 unsigned，否则你正好一半空间白给。
ALTER TABLE your_table ADD COLUMN id_bigint BIGINT UNSIGNED;
然后用脚本把老的 int 主键值同步到新字段：
UPDATE your_table SET id_bigint = id;
这一块你最好分批 update，别一次全跑爆了。
再接下来，你要把所有用到老 id 的地方，全都改成用新字段。这个事有点繁琐，什么业务代码、接口、甚至别的表的外键，都得挨个过一遍。我有次跟我们组的小李一起改了整整一晚上，到凌晨一点还在查漏补缺。
等所有地方都改好了，新的主键用上了，测试一遍没问题，再把老的 int 字段主键和自增都取消掉，然后把 bigint 字段升成主键+自增：
ALTER TABLE your_table DROP PRIMARY KEY, DROP COLUMN id, CHANGE COLUMN id_bigint id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, ADD PRIMARY KEY(id);
但其实很多公司会选择直接建新表，把历史数据全量迁移过去。这样有个好处，回滚啥的都容易，毕竟线上业务不能停啊。大不了用 pt-online-schema-change 这种工具在线改表，不过也有风险，别说我没提醒你。
我给小王举了个 Java 场景，他比较懂这个。你比如说你用 JPA 或 MyBatis 这种框架，实体类主键类型本来是 int 的，你也得全改成 long，不然取出来直接溢出。比如：
// 老代码
private Integer id;
// 新代码
private Long id;
不改，数据量大了就 GG。
对了，有朋友问那种雪花算法的分布式ID要不要用？其实这玩意儿也挺香的，你不用自增ID，改用全局唯一的 long 型ID，什么 leaf、twitter的 snowflake 实现都有。优点是不用担心自增撞线，缺点就是业务要接受长ID，不再是连续递增那种。
其实你们有时候还得注意一点，MySQL 的 int(11) 这个“11”不是数据范围，是显示宽度，跟最大值没关系，别被这个坑了。
最后小王问我要不要一开始就用 bigint？我说这看业务量，如果你才刚起步，量小，int 足够了，等真到快不够用再升，虽然听着有点鸵鸟，但现实就是这样，大公司有历史包袱，能不动就不动。要是真的新项目，建议直接上 bigint，省得后面折腾。
優網科技秉承"專業團隊、品質服務" 的經營理念，誠信務實的服務了近萬家客戶，成為眾多世界500強、集團和上市公司的長期合作伙伴！
優網科技成立于2001年，擅長網站建設、網站與各類業務系統深度整合，致力于提供完善的企業互聯網解決方案。優網科技提供PC端網站建設（品牌展示型、官方門戶型、營銷商務型、電子商務型、信息門戶型、微信小程序定制開發、移動端應用（手機站、APP開發）、微信定制開發（微信官網、微信商城、企業微信）等一系列互聯網應用服務。
公安局備案號：
專屬顧問
