MySQL 8.0 支持 RENAME COLUMN 直接改列名，仅更新元数据、不重建表、保留约束与注释；5.7 不支持该语法，必须用 CHANGE COLUMN 重写整列定义，易遗漏类型、UNSIGNED、注释及生成列表达式。
RENAME COLUMN 是 MySQL 8.0 新增的语法，5.7 完全不支持；想在 5.7 改列名，只能用 CHANGE COLUMN 或 MODIFY COLUMN 配合重写整列定义——这不是“写法不同”，而是 5.7 根本没有独立改名能力。
MySQL 8.0 用 RENAME COLUMN 直接改名
8.0 引入了语义清晰、操作轻量的专用语法，不碰数据类型和约束，只动列名本身：
ALTER TABLE t RENAME COLUMN old_name TO new_name;
- 执行快：不重建表，仅更新元数据（InnoDB 表下基本是秒级）
- 安全：不会误改类型或默认值，也不会丢掉
NOT NULL、注释等属性 - 限制：不能用于
GENERATED列；若列被视图、存储过程引用，需手动检查依赖
MySQL 5.7 只能靠 CHANGE COLUMN “伪装”改名
5.7 没有 RENAME COLUMN，必须显式写出完整列定义，稍有遗漏就会意外改掉类型、约束或注释：
ALTER TABLE t CHANGE COLUMN old_name new_name VARCHAR(255) NOT NULL COMMENT 'xxx';
- 容易漏：比如原列是
TINYINT(1) UNSIGNED，只写TINYINT就丢了UNSIGNED和显示宽度（虽已弃用，但旧业务可能依赖） - 注释会丢：
CHANGE COLUMN不带COMMENT子句时，原注释直接清空 - 虚拟列更麻烦：JSON 虚拟列表达式必须原样复写，错一个字符就建表失败
跨版本脚本怎么写才不翻车？
别试图用同一句 SQL 兼容双版本。稳妥做法是分环境判断，或统一降级为 5.7 写法（即所有改名列操作都走 CHANGE COLUMN 并补全定义）：
- 自动化部署时，先查版本：
SELECT VERSION();，再分支执行对应语句 - 人工运维场景，直接用 5.7 兼容写法最省事，哪怕在 8.0 上跑也完全合法
- 注意：8.0 的
CHANGE COLUMN对大小写更敏感——若原列名是UserName，写成username会导致新列名小写，而 5.7 可能忽略大小写差异
真正容易被忽略的是注释和生成列表达式——它们不会报错，但会静默丢失；改名不是 rename 一下就完事，得把整列“快照”下来再重放。
