mysql 5.7升级到8.0后自增主键报error 1467或1690，是因int上限溢出且8.0持久化自增值所致；需先确认max(id)与auto_increment是否已达4294967295，再通过alter table modify column扩为bigint unsigned或临时调整auto_increment值续命。
MySQL 5.7 升级到 8.0 后自增主键突然报错 ERROR 1467 或 ERROR 1690 怎么办
这不是升级导致的“新 bug”，而是旧隐患在新版本里暴露得更准——MySQL 8.0 把 AUTO_INCREMENT 值持久化进 redo log 和数据字典，重启后不再靠 SELECT MAX(id)+1 重建。如果 5.7 时代就已逼近 INT UNSIGNED 上限（4294967295），升级后自增值卡死在最大值，每次插入都尝试用同一个 ID，于是报 ERROR 1467: Failed to read auto-increment value from storage engine 或 ERROR 1690: BIGINT UNSIGNED value is out of range。
- 先确认是否真溢出：
SELECT MAX(id), AUTO_INCREMENT FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'your_db' AND TABLE_NAME = 'your_table';—— 如果AUTO_INCREMENT显示为 4294967295（或 -2147483648 / 2147483647 对应 signed INT），基本就是它了 - 别信
DESCRIBE your_table看到的Type字段就安心：int(11)默认是 signed，实际只剩 21 亿；必须显式写INT UNSIGNED才到 42 亿 - 升级本身不会自动扩容字段类型，也不会重置自增值逻辑——它只是让“已经卡住”的状态无法被重启掩盖
ALTER TABLE MODIFY COLUMN id BIGINT UNSIGNED 能不能直接跑
能跑，但线上大表极大概率锁表数小时，不是“执行完就完事”。MySQL 5.7 到 8.0 的 MODIFY COLUMN 类型变更，即使启用了 ALGORITHM=INPLACE，对整数类型扩宽（如 INT → BIGINT）仍会触发全表拷贝。
- 查表大小：
SELECT table_name, round(((data_length + index_length) / 1024 / 1024), 2) AS size_mb FROM information_schema.TABLES WHERE table_schema = 'your_db' AND table_name = 'your_table';—— 超过 50GB 就得按小时级停机窗口准备 - 磁盘空间必须 ≥ 当前表大小 × 2：InnoDB 会建临时表，原表 + 临时表同时存在
- 有外键？先
SHOW CREATE TABLE your_table;找出外键名，用ALTER TABLE ref_table DROP FOREIGN KEY fk_name;暂时移除，改完再加回，否则直接报ERROR 1832 - 低峰期操作后，立刻验证：
INSERT INTO your_table (xxx) VALUES (xxx); SELECT LAST_INSERT_ID();—— 确保返回值比之前大 1，且不为 0 或负数
不想锁表、又没时间归档，临时续命的三招
当业务完全不可中断、DBA 又批不下维护窗口，这几个操作可在分钟级生效，但属于“止血”而非根治：
-
ALTER TABLE your_table AUTO_INCREMENT = N;：只能设成比当前MAX(id)更大的值，比如当前MAX(id)是 4294967290，可设为4294967296（跳过最后 5 个），但绝不能设成4294967290或更小，否则下次插入必冲突 - 启用
innodb_autoinc_lock_mode = 2（默认值）：减少并发插入时的自增锁争用，避免因锁等待放大溢出感知延迟；确认方式：SELECT @@innodb_autoinc_lock_mode;，非 2 则需在配置文件中设置并重启 MySQL - 对冷数据做
DELETE + OPTIMIZE TABLE：仅适用于已删大量旧记录、且AUTO_INCREMENT还卡在高位的场景；OPTIMIZE TABLE会重建表并重置自增值为MAX(id)+1，但它同样锁表，且只对 MyISAM 保证立即生效，InnoDB 下效果依赖innodb_file_per_table和碎片情况
监控必须覆盖的两个关键指标
靠人工查 information_schema 不现实。真正有用的监控，是把“使用率”变成告警阈值，而不是等报错才翻日志。
- 自增值使用率：
SELECT table_name, ROUND(AUTO_INCREMENT / CASE WHEN column_type LIKE '%int%unsigned%' THEN 18446744073709551615 WHEN column_type LIKE '%int%' THEN 2147483647 ELSE 4294967295 END * 100, 2) AS usage_pct FROM information_schema.COLUMNS c JOIN information_schema.TABLES t ON c.TABLE_SCHEMA = t.TABLE_SCHEMA AND c.TABLE_NAME = t.TABLE_NAME WHERE c.TABLE_SCHEMA = 'your_db' AND c.COLUMN_NAME = 'id' AND t.AUTO_INCREMENT IS NOT NULL;—— 一旦 >70%，就得启动扩容流程 - 错误日志高频关键词：在日志采集端（如 Filebeat + ES）配
ERROR 1467、ERROR 1690、Duplicate entry.*for key 'PRIMARY'的告警，这类错误出现 3 次/小时，基本可判定已溢出 - 别漏掉隐式主键风险：如果某张表没定义主键，InnoDB 会用隐藏的 6 字节
row_id，其全局计数器上限是 2^48 ≈ 281 万亿——看似很大，但高并发写入下几年就可能撞上，且无任何提示，只能靠定期SELECT @@global.innodb_row_id;监控
最麻烦的不是改类型，而是改完发现应用层 ORM 把 BIGINT 当 INT 解析，或者前端 JavaScript 用 Number 接收导致精度丢失——这些不在数据库侧，但会让整个“扩容”失效。
