必须停写修复，因auto_increment卡死在上限（如4294967295）后每次insert均报error 1467或1690，写入实质中断；真实选择是快速锁表扩容或切流短时停写，长事务会掩盖问题直至提交时集中爆发，查状态须用select max(id), auto_increment from information_schema.tables，alter table modify column转bigint unsigned必锁表且需双倍磁盘空间，超50gb表应使用pt-online-schema-change，临时续命仅适用于auto_increment虚高而max(id)未达上限的情形。
不能不停服务修复自增主键溢出——只要 AUTO_INCREMENT 已卡死在上限值（如 4294967295），每次 INSERT 都会触发 ERROR 1467 或 ERROR 1690，此时写入已实质中断，所谓“不停服”只是幻觉。真正的选择是：快速锁表扩容，或切流+短时停写。
为什么长事务会让自增溢出“突然爆发”
长事务本身不直接导致溢出，但它会掩盖问题：事务未提交前，AUTO_INCREMENT 值不会刷新到数据字典；而 MySQL 8.0 持久化该值后，一旦事务最终提交或回滚，可能直接把自增值顶到上限。更危险的是，长事务期间其他 INSERT 仍在持续分配 ID，直到某次插入刚好撞上 4294967295 才报错，此时错误不是起点，而是终点。
- 查当前状态必须用
SELECT MAX(id), AUTO_INCREMENT FROM information_schema.TABLES，别信SHOW CREATE TABLE——它只显示建表时定义，不反映运行时真实自增值 - 如果
AUTO_INCREMENT返回4294967295（INT UNSIGNED 上限）或2147483647（INT SIGNED 上限），且MAX(id)也接近该值，说明已溢出 - 长事务结束后，InnoDB 会尝试把自增值写入 redo log 和 DD（数据字典），若此时已达上限，后续所有 INSERT 都失败
ALTER TABLE MODIFY COLUMN id BIGINT UNSIGNED 要不要锁表
要。MySQL 5.7 升级到 8.0 后，MODIFY COLUMN 从 INT 到 BIGINT 仍触发全表拷贝，ALGORITHM=INPLACE 不生效。这不是配置问题，是存储引擎限制。
- 执行前必须确认磁盘剩余空间 ≥ 当前表大小 × 2：InnoDB 创建临时表时，原表和临时表同时存在
- 有外键的表先跑
SHOW CREATE TABLE your_table，提取外键名，用ALTER TABLE ref_table DROP FOREIGN KEY fk_name临时移除外键约束，否则报ERROR 1832 - 表体积超 50GB？别硬扛——用
pt-online-schema-change分阶段改，但要注意：它仍需短暂锁主键索引，且期间禁止 DDL - 改完立刻验证：
INSERT INTO your_table (...) VALUES (...); SELECT LAST_INSERT_ID();—— 返回值必须 > 之前最大 ID，且为正数
没时间停写？试试这个临时续命方案
如果业务完全不可中断，且确认 MAX(id) 还没到上限（比如当前 MAX(id) = 4294967290，但 AUTO_INCREMENT = 4294967295），可手动调高自增值“腾出空间”，但这只是缓冲，不是解法。
- 执行
ALTER TABLE your_table AUTO_INCREMENT = 4294967290;—— 注意不是设成MAX(id)+1，而是设成略低于上限的值，留出几条插入余量 - 该操作秒级完成，不锁表，但仅适用于“自增值虚高、实际数据还没填满”的情况
- 如果
MAX(id)已等于4294967295，此操作无效：再插一条就必然冲突 - 这招治标不治本，必须同步启动
BIGINT改造，否则一周内大概率再次爆掉
真正容易被忽略的点：溢出不是发生在“插入第 4294967296 条记录时”，而是发生在“第 4294967295 条记录插入后，下一次 INSERT 尝试分配新 ID 的瞬间”。监控必须盯住 AUTO_INCREMENT 值本身，而不是只看 MAX(id)；修复必须在它触顶前动手，等报错出来，服务已经卡住了。
