自增主键快用完时应优先评估扩容风险并及时行动：先查MAX(id)和AUTO_INCREMENT值，确认类型上限；若超70%需规划将INT改为BIGINT，但须注意锁表与外键约束；临时方案包括手动调整AUTO_INCREMENT、归档冷数据、优化并发插入等；避免直接替换为UUID以防性能下降。
自增主键快用完了怎么办
MySQL 的 AUTO_INCREMENT 主键不是无限的，用到上限就会报错 ERROR 1062: Duplicate entry 'X' for key 'PRIMARY'——其实不是重复，是自增计数器卡在最大值后反复尝试插入同一个值。最直接的信号是：明明没手动插过最大值，却突然无法插入新记录。
常见场景是 INT UNSIGNED（上限 4294967295）或更小的 TINYINT/SMALLINT 类型，尤其在日活高、单表写入量大的业务中（比如订单、日志、消息表），几年就可能耗尽。
- 先查当前最大值和自增值：
SELECT MAX(id), AUTO_INCREMENT FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'your_db' AND TABLE_NAME = 'your_table';
- 确认字段类型：
DESCRIBE your_table;看id列的 Type 是否为int(11) unsigned或更小 - 别等报错才行动：当
MAX(id)超过上限的 70%，就得规划扩容
ALTER TABLE 修改主键类型要小心
把 INT 改成 BIGINT 看似一劳永逸，但线上大表执行 ALTER TABLE ... MODIFY id BIGINT UNSIGNED AUTO_INCREMENT 会锁表、重建全量数据，可能持续数小时甚至更久，业务写入完全阻塞。
- 必须在低峰期操作，且提前评估表大小和磁盘空间（临时表需要同等空间）
- MySQL 5.6+ 支持
ALGORITHM=INPLACE，但仅对某些修改有效；MODIFY COLUMN类型变更仍大概率触发拷贝，需实测SHOW PROCESSLIST中是否出现copy to tmp table - 如果表有外键，必须先
DROP FOREIGN KEY，改完再加回，否则报错ERROR 1832: Cannot change column 'id': used in a foreign key constraint - 改完立刻验证：
INSERT一条新记录，检查LAST_INSERT_ID()是否正常递增
不改类型也能续命的实用方案
如果暂时不能动表结构，或者担心 BIGINT 带来存储/索引膨胀（虽然实际影响极小），可以用逻辑层控制 + 数据归档组合止损。
- 启用
innodb_autoinc_lock_mode = 2（默认值），避免语句级自增锁争用，提升并发插入稳定性 - 用
ALTER TABLE your_table AUTO_INCREMENT = N手动跳过已知空洞（例如删过大量旧数据后），但不能设得比当前最大值小，否则下次插入会冲突 - 对历史冷数据做归档：把
created_at < '2023-01-01'的记录迁出，再DELETE，然后OPTIMIZE TABLE释放空间并重置AUTO_INCREMENT基值（注意：该操作也会锁表） - 业务侧控制：关键流水号类字段可改用
REPLACE INTO+ 时间戳+随机数生成唯一键，主键只作索引用途，降低对自增连续性的依赖
为什么别用 UUID 或雪花 ID 替代自增主键
看到溢出就想着换 UUID，容易掉进另一个坑：InnoDB 的聚簇索引要求主键尽量有序。UUID 是随机字符串，插入时会导致频繁页分裂、索引碎片暴涨、写性能断崖下跌。
-
UUID()生成的值无序，INSERT吞吐量可能下降 3–5 倍，SELECT范围查询变慢 - 雪花 ID（如 Twitter Snowflake）虽有序，但 MySQL 没原生支持，需应用层生成，且 64 位整数在 MySQL 里必须用
BIGINT存，跟直接扩类型没本质区别 - 真正适合替代的，是复合主键（如
(shard_id, auto_inc_id)）或分库分表路由，但这属于架构调整，不是单表自增问题的解法
自增溢出的本质是容量预估偏差，而不是技术选型错误。最容易被忽略的是：开发阶段用 INT 图省事，测试环境数据量小根本压不出问题，上线后两三年才爆发——这时候再改，代价远大于一开始选 BIGINT。
