MySQL改字段名必须用CHANGE而非RENAME COLUMN，因后者仅支持8.0+且不能改类型或约束；CHANGE需重复写旧名与新名并显式重申全部属性（类型、NULL/NOT NULL、DEFAULT、COMMENT等），否则易导致空值允许、默认值丢失等问题，且会锁表重建。
MySQL 修改字段名必须用 CHANGE，不能只用 RENAME COLUMN
MySQL 8.0+ 确实支持 RENAME COLUMN，但它只能改名、不能改类型或约束；而实际中多数人想改字段名时，顺手也想调类型、加 NOT NULL 或改默认值——这时必须用 CHANGE。否则会报错：ERROR 1064 (42000): You have an error in your SQL syntax。
常见错误现象：直接写 ALTER TABLE t1 RENAME COLUMN old_name TO new_name;，结果发现字段没变、或者提示语法不支持（尤其在 MySQL 5.7 或更低版本）。
-
CHANGE要求你**重复写两次字段名**：第一次是旧名，第二次是新名（哪怕只改名不改类型，也得把原定义再写一遍） - 如果只想改名且保持所有属性不变，最安全的做法是先用
SHOW CREATE TABLE table_name;查出完整字段定义，再套进CHANGE - MySQL 5.7 及更早版本不支持
RENAME COLUMN，强行用会直接报错，不是警告
用 CHANGE 改字段名时，类型和属性必须显式重写
CHANGE 的语法本质是「删除旧字段 + 新增同名字段」，所以它强制你提供完整的列定义。哪怕只是把 user_name 改成 username，也得把类型、是否允许 NULL、默认值等全写出来。
示例：要把 users 表里的 user_name（类型 VARCHAR(50)，允许 NULL）改成 username：
ALTER TABLE users CHANGE user_name username VARCHAR(50) NULL;
注意：NULL 或 NOT NULL 必须明确写出，否则默认变成 NULL（即使原字段是 NOT NULL）。
- 漏写
NOT NULL是高频翻车点，改完后字段突然允许空值，业务逻辑可能崩 - 如果原字段有
DEFAULT，比如DEFAULT 'guest'，CHANGE里也得带上，否则默认值丢失 - 带
COMMENT的字段，注释不会自动继承，要手动加COMMENT 'xxx'
改名过程会锁表，大表务必避开高峰期
MySQL 在执行 ALTER TABLE ... CHANGE 时，对整张表加元数据锁（MDL），并重建表（除非用 ALGORITHM=INSTANT，但仅限部分简单变更）。这意味着：写操作会被阻塞，读操作也可能被卡住，尤其是 MyISAM 引擎会直接锁死整个表。
使用场景判断：
- 表行数
- 表超百万行，或在线服务核心表：优先考虑
pt-online-schema-change工具，或安排维护窗口 - MySQL 8.0.12+ 且只改名不改类型/约束/长度，可尝试
ALGORITHM=INSTANT（需满足严格条件，如字段不在主键/索引中作为前导列）
外键、索引、视图、存储过程可能悄悄失效
字段名一改，依赖它的对象不会自动更新。最常被忽略的是：
- 外键约束名本身不包含字段名，但外键定义里的列名变了，会导致
SHOW CREATE TABLE输出异常，甚至后续DROP FOREIGN KEY失败 - 已有索引如果基于该字段（比如
INDEX idx_user_name (user_name)），索引名不变，但内部指向的列已不存在——索引实际还生效，但语义上已“脱钩” - 视图、触发器、存储过程中硬编码了旧字段名，查询时直接报错：
ERROR 1054 (42S22): Unknown column 'user_name' in 'field list' - 应用层 ORM（如 Laravel Eloquent、Django Model）若用了字段别名或手动写了 SQL，也会挂掉
真正麻烦的从来不是那条 ALTER 语句，而是改完之后，谁还记得数据库里还有三个视图、两个定时任务脚本、一个老接口的 SQL 拼接里写着 user_name。
