MySQL 5.7 中 MODIFY COLUMN 大概率锁表、丢数据、失效索引，因其多触发 COPY 算法而非 INPLACE；需查长度分布、原字段定义及索引依赖，并优先用 pt-online-schema-change 或分步双写实现安全变更。
MySQL 5.7 中直接用 ALTER TABLE ... MODIFY COLUMN 修改大表字段类型，大概率锁表、丢数据、失效索引——不是“能不能”，而是“敢不敢”。
为什么不能直接执行 MODIFY COLUMN？
MySQL 5.7 的 Online DDL 能力有限，MODIFY COLUMN 在多数字段类型变更场景下会触发 COPY 算法（全表重建），而非 INPLACE。这意味着：
- 写操作被阻塞，读操作可能被长事务卡住（MDL 锁）
- 百万行以上表，执行时间常达数分钟甚至更久
- 隐式截断风险高：比如
VARCHAR(255) → VARCHAR(50)，超长值静默被砍，无报错 - 原有
COMMENT、DEFAULT、NOT NULL属性不会自动继承，漏写就丢了
改之前必须查清楚这三件事
别跳过验证，否则上线后才发现数据被截断或查询变慢，代价远高于多花五分钟。
-
SELECT MIN(col), MAX(col), AVG(LENGTH(col)), COUNT(*) FROM tbl WHERE col IS NOT NULL;—— 查长度分布，确认缩容是否安全 -
SHOW CREATE TABLE tbl\G—— 复制原字段定义，包括NOT NULL、DEFAULT、COMMENT、COLLATE全部细节 -
SELECT * FROM INFORMATION_SCHEMA.STATISTICS WHERE TABLE_NAME = 'tbl' AND COLUMN_NAME = 'col';—— 看该字段是否在主键、联合索引最左位、外键中；若在，ALGORITHM=INSTANT不生效，且索引可能失效
真正安全的实操路径（针对大表）
不依赖“运气”，用可中断、可回滚、低影响的方式推进：
- 优先用
pt-online-schema-change（Percona Toolkit）：它通过影子表+触发器实现无锁变更，支持 MySQL 5.7，是线上大表修改的事实标准 - 若无法装第三方工具，至少分两步走：
– 第一步：加新字段（ADD COLUMN new_col TYPE），用应用双写或触发器同步历史数据
– 第二步：切换读写逻辑，再删旧字段（DROP COLUMN old_col） - 绝对不要在业务高峰执行；提前在从库上试跑，观察复制延迟和磁盘 IO
- 执行前备份：
mysqldump --single-transaction --no-create-info db tbl > backup.sql（注意--single-transaction对 MyISAM 无效）
容易被忽略的坑点
很多问题不是语法错，而是语义没吃透：
-
MODIFY COLUMN和CHANGE COLUMN都不保留COMMENT，哪怕你只改类型也得手动补上COMMENT 'xxx' - 把
TIMESTAMP改成DATETIME后，原有时区自动转换逻辑消失，应用层WHERE time_col = '2025-01-01'可能查不到数据 -
TEXT类型字段变更（哪怕只是TEXT → MEDIUMTEXT）在 5.7 中仍强制 COPY，且需确保表ROW_FORMAT=DYNAMIC，否则报ERROR 1118 - 字段参与了视图、存储过程或触发器？
ALTER不会更新这些对象，改完立刻报Unknown column 'old_name'
事情说清了就结束。真正麻烦的从来不是 ALTER TABLE 怎么写，而是改之前没看懂那条数据到底在哪儿被截断、哪个索引悄悄失效、哪次锁表让下游等了三分钟。
