安全，但需满足条件：数据量适中、无长事务与高并发写入；MySQL 5.6/5.7会锁表重建，8.0.12+在严格条件下支持INSTANT；必须显式保留UNSIGNED/NOT NULL/AUTO_INCREMENT等约束，并同步更新应用层类型。
自增主键快用尽时，ALTER TABLE改BIGINT是否安全？
直接说结论：只要表数据量不是超大（比如上十亿行），且没有长事务或高并发写入正在执行，ALTER TABLE ... MODIFY COLUMN在线修改主键类型为BIGINT是可行的；但MySQL 5.6/5.7默认是inplace不支持的，会触发copy重建表，锁表时间取决于数据量。
常见错误现象：ERROR 1062 (23000): Duplicate entry '9223372036854775807' for key 'PRIMARY' 或插入时报Out of range value——说明INT UNSIGNED（最大值4294967295）或INT SIGNED（最大值2147483647）已逼近上限。
- 必须确认当前主键是否真为
INT：执行SHOW CREATE TABLE `your_table`;查看id字段定义，注意是否有UNSIGNED - 若使用
AUTO_INCREMENT，改完类型后需同步检查并可能调整AUTO_INCREMENT值：例如原INT UNSIGNED已到4294967295，改BIGINT后应手动设为ALTER TABLE your_table AUTO_INCREMENT = 4294967296; -
MySQL 8.0.12+支持ALGORITHM=INSTANT对某些列类型变更（含INT → BIGINT），但仅限于无默认值、无索引前缀等严格条件，实际中建议先测试
执行MODIFY COLUMN前必须做的三件事
别跳过验证步骤，否则可能阻塞线上服务数小时。
- 查当前最大ID：
SELECT MAX(id) FROM your_table;，确认是否接近INT上限（如 > 21亿或 > 42亿） - 评估表大小和维护窗口：
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';。超过500MB就要谨慎，优先考虑从库操作+主从切换 - 备份+锁表影响预估：在低峰期执行，并提前在测试环境跑一遍完整流程。尤其注意
innodb_lock_wait_timeout和lock_wait_timeout是否过短，导致DDL中途失败
ALTER TABLE ... MODIFY COLUMN的正确写法与参数陷阱
不是所有MODIFY都能成功，字段属性必须显式补全，否则会丢掉NOT NULL、UNSIGNED、AUTO_INCREMENT等关键约束。
假设原定义是：`id` int(11) unsigned NOT NULL AUTO_INCREMENT
正确写法是：
ALTER TABLE your_table MODIFY COLUMN id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT FIRST;
-
FIRST可选，但建议加上，避免字段顺序意外变动（尤其当表有多个自增列时） - 必须重申
UNSIGNED——如果原字段是unsigned，漏写会导致后续插入负数或截断 - 不能只写
BIGINT，必须带完整约束，否则NOT NULL可能被隐式去掉，引发后续应用报错 - 执行后务必验证：
SHOW COLUMNS FROM your_table LIKE 'id';和SELECT AUTO_INCREMENT FROM information_schema.TABLES WHERE TABLE_SCHEMA='your_db' AND TABLE_NAME='your_table';
改完之后，应用层最容易忽略的两个点
数据库改完了，不代表万事大吉。很多问题出在客户端代码或ORM配置里。
- Java的
MyBatis或JPA实体类中，对应字段仍为int或Integer，插入超21亿的ID会溢出变成负数，必须同步改为long/Long - Go的
sql.Scanner或GORM中，若用int接收BIGINT列，在32位系统或误配int类型时会panic；建议统一用int64 - PHP的
PDO默认把整数作为string返回（尤其开启PDO::ATTR_STRINGIFY_FETCHES），但有些老代码用(int)强转，遇到大于PHP_INT_MAX的值会回绕，得改用gmp_init()或保持字符串处理
最麻烦的不是改数据库，而是改完之后发现某个冷门报表导出接口用了硬编码的int数组缓存ID，一查才发现它每天凌晨批量拉取，已经悄悄错失了三个月的数据。
