MySQL 修改字段注释用 MODIFY 还是 CHANGE？
开门见山，先说结论：要用 CHANGE，而不是 MODIFY。原因很简单，MODIFY 命令的权限不够——它只能调整数据类型和 NULL 约束，一旦执行，字段原有的注释就会被悄无声息地抹掉。而 CHANGE 命令则要求你重写整个字段的定义，这恰恰给了你一个机会，把新的注释名正言顺地带进去。
是不是经常遇到这种怪事：执行了 ALTER TABLE t MODIFY COLUMN c INT COMMENT 'new';，系统提示成功，可一查注释纹丝不动？这就是典型的语法陷阱，很多人都在这里栽过跟头。
使用 CHANGE 时，有几个细节必须盯紧：
- 字段名必须写两遍，哪怕不改名，新旧名字也得一模一样。
- 字段的类型、约束（比如
NOT NULL）、默认值等定义必须完整写出，任何遗漏的部分都会被重置为默认状态。 - 特别要小心，如果字段原本有默认值或生成表达式，重写时漏掉了，它们可就真的消失了。
给已有字段加注释的最小安全写法
这里有个核心原则：先查后改，照抄作业。千万别凭记忆手写，风险太高。
具体怎么操作？四步走：
- 第一步，用
SHOW CREATE TABLE把表结构的“底稿”调出来。; - 第二步，找到目标字段那一行完整的定义，比如
`status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '订单状态'，原样复制。 - 第三步，只动手术刀，把
COMMENT后面的内容换成新的注释，其他部分一个字符都别动。 - 第四步，套进
ALTER TABLE ... CHANGE的模板里，记得字段名要重复写一遍。
举个例子，如果想给 user 表的 nick 字段加上注释，安全的写法是这样的：
ALTER TABLE user CHANGE COLUMN nick nick VARCHAR(50) NOT NULL COMMENT '用户昵称，仅前台显示';
为什么不用 ALTER TABLE ... ALTER COLUMN ... SET COMMENT？
看到这个语法，可能有人会觉得更简洁。没错，这是 MySQL 8.0.13 版本之后新增的特性。但它有个前提：要么是在 ADD COLUMN 时直接设置注释，要么是配合 MODIFY COLUMN 修改类型时顺带更新。如果想单独修改一个已有字段的注释，这个语法在当前很多主流版本（比如 5.7 系列，或者 8.0.12 及更早的版本）里是行不通的，直接会报 ERROR 1064 语法错误。
这意味着：
- 即便在 8.0.13+ 的版本中，这个语法也只能用于“不改变任何类型和约束，只更新注释”的场景。
- 现实是，大量的生产环境还没有升级到那么新的版本，盲目使用就等于埋下了兼容性的地雷。
- 所以，从稳定和兼容的角度出发，
CHANGE仍然是目前最可靠、最通用的方案。
注释里不能写什么？特殊字符和长度限制
MySQL 虽然不会去解析 COMMENT 里的语义，但有两道“硬杠杠”很容易被忽略，导致注释存不进去或者存错了：
- 长度限制：注释内容最大支持 1024 个字符（包括空格和换行）。超过的部分会被静默截断，系统不会给你任何错误提示。
- 特殊字符：单引号、双引号、反斜杠这些字符需要正确转义，否则在程序拼接 SQL 时很容易破坏语句结构，引发解析错误。
- 另外，在注释里写
/* */或者--并不会被当成 SQL 注释，它们只是普通文本。但这可能会干扰其他开发者阅读，所以一般也不建议。
有个实用建议：注释内容尽量用英文逗号分隔关键信息，避免嵌套使用引号。在上线前，最好通过查询 INFORMATION_SCHEMA.COLUMNS 系统表，核对一反赌释是否完整准确地写入了。
最后提个更棘手的问题：跨版本迁移。从低版本数据库导出的建表语句，其字段注释可能会被忽略。当导入到高版本时，这些注释就丢了，只能手动补回来。这个问题无法通过语法技巧规避，只能在数据迁移的流程中，把它作为一个必须检查的卡点。
