直接 MODIFY COLUMN 修改主键字段类型（如 INT → BIGINT）必然触发表重建并阻塞 DML；应使用 pt-online-schema-change 无锁变更，或人工分步操作（先删主键、再改类型、最后重加主键），严禁 UPDATE 绕行。
直接 MODIFY COLUMN 会锁表，别这么干
MySQL 的 ALTER TABLE ... MODIFY COLUMN 在修改主键字段类型（比如 INT → BIGINT）时，默认走的是「原地重建」或「拷贝表」路径，取决于版本和存储引擎。5.6+ 的 InnoDB 支持 ALGORITHM=INPLACE，但仅限部分操作；而修改主键列类型 **不在此列** —— 它必然触发表重建，整个过程持有 SX 或 X 锁，DML（INSERT/UPDATE/DELETE）会被阻塞，线上写入停摆。这不是“慢”，是“卡死”。
用 pt-online-schema-change 做无锁变更
Percona Toolkit 的 pt-online-schema-change 是目前最稳妥的方案。它不直接改原表，而是新建影子表、同步数据、逐步切换，全程允许原表读写。关键点：
- 必须有唯一非空索引（主键或等效唯一键），否则无法做增量同步
- 执行前确保磁盘空间 ≥ 原表大小 × 2（影子表 + binlog 日志膨胀）
- 命令示例：
pt-online-schema-change --alter "MODIFY id BIGINT NOT NULL" D=your_db,t=users --execute - 它会自动检查外键、触发器、复制延迟，并在切换前做一致性校验
手动分步操作：只适用于低峰期且能接受短时中断
如果无法引入第三方工具，只能人工分步，但必须按顺序、带验证：
- 先
ALTER TABLE users DROP PRIMARY KEY—— 此时主键约束消失，但聚集索引仍在（InnoDB 仍按原主键物理排序） - 再
ALTER TABLE users MODIFY id BIGINT NOT NULL—— 这步仍可能锁表，但至少不校验主键唯一性了 - 最后
ALTER TABLE users ADD PRIMARY KEY (id)—— 这步最重，需全表扫描去重校验，务必在业务低峰执行 - 每步后都查
SHOW CREATE TABLE users确认结构，再查SELECT COUNT(*) FROM users WHERE id IS NULL防止隐式转空值
为什么不能 UPDATE 主键值来“绕开”类型变更
有人想先改数据再改类型，比如 UPDATE users SET id = id + 0 强制类型转换。这完全无效：
-
UPDATE不改变列定义，只是把当前值按规则转义后存回去，INT字段里永远存不了超范围的BIGINT值 - 若原值已超
INT上限（2147483647），更新会截断或报错，且主键冲突风险极高 - 更危险的是：如果有外键引用该主键，
UPDATE会级联失败或违反约束，直接报ERROR 1452
真正难的不是语法，是判断「是否真需要改主键类型」——很多场景其实该加一个 BIGINT 业务唯一键，保留原主键不动。主键一旦上线，它的物理结构、复制行为、应用缓存逻辑就全绑定了，动它就得像拆弹一样步步核对。
