MODIFY COLUMN 可能丢失数据——类型不兼容时会静默截断或转默认值，不保留注释，JSON/ENUM/SET 变更受限；改名+改类型用 CHANGE，仅改类型用 MODIFY；TEXT/BLOB 变更仍锁表；类型变更可能导致索引失效或时区逻辑变化。
ALTER TABLE MODIFY COLUMN 会丢失数据吗
不一定丢，但风险很高——MODIFY COLUMN 在字段类型不兼容时会静默截断或转为默认值，比如把 VARCHAR(10) 改成 VARCHAR(5)，超长值直接被砍掉；把 INT 改成 TINYINT，超出 -128~127 的数变成 127 或 -128。
- 改前务必用
SELECT COUNT(*) FROM table WHERE LENGTH(column) > new_length检查长度风险 -
MODIFY COLUMN不保留原有列注释（COMMENT），要手动补上 - MySQL 8.0+ 对
JSON、ENUM、SET类型变更限制更严，改错会直接报错ER_CANT_CHANGE_ENUM
CHANGE COLUMN 和 MODIFY COLUMN 到底选哪个
只改类型不改名，用 MODIFY COLUMN；要同时改名+改类型，才用 CHANGE COLUMN。后者语法更啰嗦，还容易手抖写错两次列名。
-
MODIFY COLUMN col_name NEW_TYPE—— 简洁，安全边界清晰 -
CHANGE COLUMN old_name new_name NEW_TYPE—— 第二个参数必须和第一个一致才能只改类型，极易出错 - 如果列有默认值、非空约束、自增属性，
MODIFY会保留；CHANGE必须显式重写全部属性，漏写就丢了
修改 TEXT/BLOB 类型字段时的锁表现
MySQL 5.6+ 对大字段变更仍需全表拷贝，不是 Online DDL —— 即使只是把 TEXT 改成 MEDIUMTEXT，也会锁表、阻塞写入，时间取决于表大小。
- 确认是否支持 Online DDL：执行
SHOW CREATE TABLE table_name，看存储引擎是不是InnoDB；再查 MySQL 版本是否 ≥ 5.6 - 对千万级以上表，优先考虑分批导出+重建，而不是硬扛
ALTER -
ALGORITHM=INPLACE, LOCK=NONE对多数 TEXT 类型变更无效，不要盲目加
修改字段类型后索引失效的常见情况
类型变更可能让原有索引无法用于查询，尤其是隐式类型转换触发的失效。比如把 VARCHAR 改成 CHAR，或 INT 改成 BIGINT 后，WHERE 条件里用字符串比较，优化器可能放弃走索引。
- 改完立刻执行
EXPLAIN SELECT * FROM table WHERE column = ?验证执行计划 - 如果字段是联合索引最左前缀，类型变窄（如
VARCHAR(255)→VARCHAR(50)）一般不影响；变宽则无影响 - 从
TIMESTAMP改成DATETIME后，原有时区自动转换逻辑消失，应用层时间对比可能出偏差
事情说清了就结束。真正麻烦的从来不是语法怎么写，而是改之前没看懂那条数据到底在哪儿被截断、哪个索引悄悄失效、哪次锁表让下游等了三分钟。
