MySQL 5.6+中ALTER TABLE ... MODIFY COLUMN是否锁表取决于是否触发行格式重写：VARCHAR长度调整通常不锁表，但改类型、加NOT NULL等可能全表重建锁表；pt-osc可避免DML阻塞但有触发器开销；INSTANT仅支持增删列/重命名，不支持任何类型变更。
ALTER TABLE ... MODIFY COLUMN 会锁表吗？
在 MySQL 5.6 及以上版本中，ALTER TABLE ... MODIFY COLUMN 是否锁表，取决于字段类型变更是否涉及行格式重写。比如从 VARCHAR(10) 改成 VARCHAR(255)，大多数情况是 INSTANT 或 INPLACE，不锁表；但改成 TEXT、增加 NOT NULL、或从 INT 改成 BIGINT（旧版本），就可能触发 COPY 算法，全表重建+锁表。
- 用
SHOW CREATE TABLE查当前行格式（ROW_FORMAT=Dynamic更友好） - 执行前加
ALGORITHM=INPLACE, LOCK=NONE显式声明（MySQL 5.6+），失败时立刻报错，不会静默降级 - 注意：即使声明
LOCK=NONE，某些操作（如修改主键字段）仍强制要求LOCK=SHARED，需提前查 官方 DDL 兼容表
pt-online-schema-change 能完全避免锁表吗？
不能“完全避免”，但能规避 DML 阻塞。它本质是创建影子表 + 触发器同步 + 重命名切换，主表全程可读写。不过有隐性代价：
- 触发器本身有开销，高并发写入下可能拖慢主表性能（尤其大字段或复杂条件）
- 如果原表没主键或唯一索引，
pt-online-schema-change会拒绝执行（无法安全打点同步） - 必须确保
binlog_format=ROW，否则触发器同步可能丢数据 - 运行期间磁盘空间要预留 ≥ 原表大小（影子表+日志）
示例命令：pt-online-schema-change --alter "MODIFY COLUMN name VARCHAR(100)" D=test,t=user --execute
MySQL 8.0 的 INSTANT ADD COLUMN 不适用于改类型
INSTANT 只支持新增列（且不能含默认值表达式）、删列、重命名列，**不支持任何类型变更操作**。哪怕只是把 TINYINT 改成 SMALLINT，也会退回到 INPLACE 或 COPY 模式。
- 确认是否走
INSTANT：执行后查INFORMATION_SCHEMA.INNODB_TABLES中的ALGORITHM字段，或看SHOW PROCESSLIST是否长时间卡在copy to tmp table - 想最小化影响，优先考虑“新增字段 + 应用层双写 + 渐进迁移”，而不是硬改旧字段
- 对 JSON 字段改类型尤其危险——MySQL 8.0 对
JSON列的 DDL 支持仍有限，MODIFY COLUMN j JSON可能意外触发全表拷贝
线上改字段前必须验证的三件事
不是跑完命令就完事。真正出问题的，往往在看似成功的那一次。
- 检查从库延迟：
SHOW SLAVE STATUS\G中的Seconds_Behind_Master，DDL 在主库执行后会阻塞从库 SQL 线程直到应用完，延迟突增说明复制压力大 - 确认应用连接池未缓存旧表结构（比如 MyBatis 的
resultMap或 JPA 的实体字段类型），否则改完字段，应用读到NULL或抛SQLException - 查
performance_schema.table_lock_waits_summary_by_table，确认该表近期没有其他长事务持有META DATA LOCK，否则你的 DDL 会卡在等待锁阶段，表现像“假死”
最麻烦的不是锁表本身，是锁表时没人知道它正在等另一个凌晨三点还没提交的事务。
