如何处理MySQL中的自增ID用尽问题_将INT类型修改为BIGINT-mysql教程-PHP中文网

直接alter table modify id bigint会卡住，因mysql需重建整表并重排每行物理结构，锁表时间随数据量剧增；即使5.6+支持inplace，修改数值类型仍不适用，且外键、触发器或高频写入会加剧阻塞与超时。

如何处理mysql中的自增id用尽问题_将int类型修改为bigint

为什么直接 ALTER TABLE MODIFY id BIGINT 会卡住？

因为 MySQL 默认的 ALTER TABLE 在修改列类型时会重建整张表，锁表时间与数据量正相关。一张几百 GB 的表执行 ALTER TABLE t MODIFY id BIGINT UNSIGNED AUTO_INCREMENT，可能持续数小时，期间写入完全阻塞。

更危险的是：如果表上有外键、触发器或正在被应用高频写入，该操作极易触发超时或主从延迟飙升。

MySQL 5.6+ 支持 ALGORITHM=INPLACE，但仅限某些变更（如加索引），修改数值类型不支持原地升级
BIGINT 占用 8 字节，INT 占 4 字节，InnoDB 必须重排每行记录的物理结构
即使使用 pt-online-schema-change 或 gh-ost，也需确保 id 列无 UNIQUE 约束以外的索引依赖（比如联合索引里含 id）

gh-ost 迁移时，AUTO_INCREMENT 值怎么同步？

gh-ost 不会自动继承原表的 AUTO_INCREMENT 值——它新建的影子表初始 AUTO_INCREMENT = 1。若不做处理，切流后新插入数据会从 1 开始，必然冲突。

正确做法是在迁移前手动设置影子表的起始值：

gh-ost \
--max-load='Threads_running=25' \
--critical-load='Threads_running=50' \
--chunk-size=1000 \
--throttle-control-replicas="replica-host" \
--database="db" \
--table="t" \
--alter="MODIFY id BIGINT UNSIGNED AUTO_INCREMENT" \
--assume-rbr \
--allow-on-master \
--cut-over=default \
--exact-rowcount \
--concurrent-rowcount \
--default-retries=120 \
--panic-flag-file=/tmp/ghost.panic.flag \
--postpone-cut-over-flag-file=/tmp/ghost.postpone.flag \
--initially-drop-ghost-table \
--initially-drop-old-table \
--execute

迁移完成后，立即执行：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

ALTER TABLE _t_gho AUTO_INCREMENT = (SELECT AUTO_INCREMENT FROM information_schema.TABLES WHERE TABLE_SCHEMA='db' AND TABLE_NAME='t');

否则切流瞬间就会因主键重复失败。

改完 BIGINT 后，外键和应用代码要动哪些地方？

改动不止在数据库层。忽略以下任一环节，上线后大概率报错：

FOREIGN KEY 关联的子表字段也必须同步改为 BIGINT，否则 INSERT/UPDATE 外键列会报 ERROR 1215 (HY000): Cannot add or update a child row
Java 应用中，int 类型的 ID 字段必须升级为 long；MyBatis 的 resultMap 和 parameterType 也要同步改，否则 JDBC 驱动可能截断高位
PHP 中 intval() 会把超过 PHP_INT_MAX（通常为 2^63−1）的 BIGINT 强转成负数，应改用 string 接收再转 GMP 或 bcmath
前端 JavaScript 注意：Number.MAX_SAFE_INTEGER 是 2^53−1，BIGINT 超过此范围会丢失精度，建议 API 返回 ID 为字符串