当自增id接近int上限2147483647时，应执行alter table ... modify id bigint unsigned auto_increment；需检查max(id)和auto_increment值，避免越界插入失败，并同步更新应用层orm、备份、cdc及连接池配置。
自增ID快用完时，SHOW CREATE TABLE 看到的 INT 类型怎么改
MySQL 的自增主键一旦定义为 INT（默认有符号），最大值是 2147483647；如果业务写入频繁，这个数可能半年就撞上。直接改类型最常用，但不是所有情况都能安全执行。
关键看当前最大值是否已接近上限：查 SELECT MAX(id) FROM table_name;，如果结果 > 20 亿，就得动了。
- 用
ALTER TABLE table_name MODIFY id BIGINT UNSIGNED AUTO_INCREMENT;是最稳妥的升级路径，BIGINT UNSIGNED支持到 18446744073709551615 - 不能只改成
BIGINT（有符号），否则上限还是 9223372036854775807，虽大但浪费一半空间，且和常见 ORM 默认映射不一致 - 如果表很大（比如 > 100GB），
MODIFY会锁表、重建，必须在低峰期操作，或提前用pt-online-schema-change - 注意应用层：Java 的
int接收不了BIGINT，Python 的int没问题，但 SQLAlchemy 或 Django ORM 需同步改字段声明
ERROR 1467 (HY000): Failed to read auto-increment value from storage engine 是什么信号
这不是普通报错，是 MySQL 已经发现自增计数器“算不过来了”——比如当前 auto_increment 值设成了 2147483648，但字段还是 INT，插入时引擎根本没法生成合法 ID。
此时表还能查，但任何 INSERT（哪怕显式指定 ID）都可能失败，尤其触发自增逻辑时。
- 立刻查
SELECT AUTO_INCREMENT FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'db_name' AND TABLE_NAME = 'table_name'; - 如果返回值 > 2147483647，说明计数器已越界，必须先停写，再改类型
- 别信
SET AUTO_INCREMENT = xxx能绕过去——它不检查字段类型，只是强行设置计数器，下次插入照样崩 - 某些云厂商 RDS（如阿里云）会在监控里预警 “AutoIncrementNearMax”，比报错早 1–2 天，要盯住
为什么不能靠 TRUNCATE TABLE 重置自增 ID 来续命
有人想清空旧数据、让 ID 从 1 重新开始，这在测试环境可行，生产几乎没用。
因为真实场景下，ID 往往被其他表外键引用、被日志系统记录、被前端缓存，甚至作为订单号一部分对外暴露。删了数据，关联关系和业务语义就断了。
-
TRUNCATE会重置AUTO_INCREMENT，但也会清空所有行，且不可回滚（InnoDB 下本质是 drop + recreate） - 即使你只删历史归档数据，
DELETE不重置计数器，ALTER TABLE ... AUTO_INCREMENT = 1又会被引擎拒绝（如果当前最大 ID 还在） - 更隐蔽的坑：
TRUNCATE后新插入的 ID 虽小，但时间戳、业务含义全乱，下游依赖 ID 顺序做分页或排序的代码会出错
上线前必须确认的三个兼容性点
改完类型不是万事大吉，很多故障出在周边系统没对齐。
- 备份恢复：mysqldump 默认导出建表语句，但如果用了
--skip-create-options或旧版客户端，可能漏掉UNSIGNED，恢复后又变回INT - Binlog 解析：Flink CDC、Canal 等工具若用老版本，可能把
BIGINT UNSIGNED当作负数解析（因为 MySQL binlog 内部用 signed 表示 unsigned big int） - 连接池配置：Druid、HikariCP 的
connectionInitSql若含SET sql_mode=...，要确认不含NO_UNSIGNED_SUBTRACTION，否则涉及 unsigned 字段的计算可能异常
自增 ID 溢出不是孤立事件，它背后连着数据生命周期、上下游契约、运维链路。改类型只是最表层动作，真正难的是确认所有依赖方是否准备好接受更大的数字——尤其是那些你以为“跟 ID 无关”的地方。
