该用 MODIFY COLUMN 时是只改字段类型、长度、NULL性、默认值或注释且字段名不变；必须用 CHANGE COLUMN 时是涉及重命名或需调整字段物理位置。
什么时候该用 MODIFY COLUMN？
当你只改字段的类型、长度、是否允许 NULL、默认值或注释，但字段名完全不变时，MODIFY 是最直接、最安全的选择。它语义清晰，语法简洁，不容易手误。
- 不需重复写字段名，少出错：比如把
username VARCHAR(50)扩到VARCHAR(100)，只需ALTER TABLE users MODIFY COLUMN username VARCHAR(100) - 不能重命名字段——如果硬要写成
CHANGE那样重复字段名，会报错 - 对自增列（
AUTO_INCREMENT）友好：修改类型时只要保留AUTO_INCREMENT属性，MySQL 会自动延续当前最大值；而CHANGE在某些旧版本中可能意外丢掉该属性（尤其没显式声明时）
什么时候必须用 CHANGE COLUMN？
只要涉及字段重命名，哪怕只是改一个字母，就必须用 CHANGE。它不是“更高级的 MODIFY”，而是功能上不可替代的命令。
- 语法强制要求写出原名和新名，哪怕两者一样：例如只改类型又不想重命名，也得写
CHANGE COLUMN age age TINYINT NULL - 容易踩坑：漏写新字段名、拼错新名、忘记补上原数据类型（即使没变），都会导致语法错误或字段被清空
- 支持精细控制位置：配合
AFTER或FIRST可调整字段在表中的物理顺序，MODIFY不支持这个能力
MODIFY 和 CHANGE 修改约束时的行为差异
两者都能加/删 NOT NULL、设 DEFAULT、加 COMMENT，但处理逻辑不同： MODIFY 是“覆盖式重定义”，CHANGE 是“重建式替换”。这意味着：
- 用
MODIFY改类型时，未显式声明的原有约束（如DEFAULT '2020-01-01'）会被清除，除非你重新写上 - 用
CHANGE时，所有约束都必须完整重写——漏掉NOT NULL就等于改成允许NULL，漏掉COMMENT就等于删除注释 - 如果字段有索引（比如是联合索引的一部分），
CHANGE可能隐式触发索引重建，而MODIFY在仅改长度等轻量操作时可能跳过重建（取决于 MySQL 版本和存储引擎）
生产环境改字段前必须确认的三件事
无论选 MODIFY 还是 CHANGE，线上表结构变更的风险不在语法本身，而在执行过程和影响范围。
- 先查当前定义：
SHOW CREATE TABLE table_name\G，确认字段现有类型、约束、索引依赖，避免“以为没默认值，其实有”这类低级失误 - 检查是否有应用正在读写该字段：尤其是
TEXT/BLOB类型或大字段，MODIFY可能锁表数秒至数分钟（InnoDB 在 5.6+ 支持在线 DDL，但并非全部操作都免锁） - 别信“小修改就不用备份”：哪怕只是把
TINYINT改成SMALLINT，一旦遇到磁盘满、连接中断、权限不足，回滚成本远高于提前导出mysqldump -d表结构
CHANGE 的“重建”本质比 MODIFY 的“就地更新”更容易暴露隐藏依赖。 
