MySQL注释分SQL语句级（--、#、/ /，不执行）和元数据级（COMMENT，存information_schema），混用易出错；COMMENT字段修改需保持原类型完整，验证须查系统表。
MySQL 中注释分两类：SQL 语句级注释（用于注释代码本身）和元数据级注释（用于表/字段的业务说明），二者用途、语法、存储位置完全不同，混用会导致预期外行为。
SQL 语句里的单行/多行注释怎么写
这是写在 SQL 脚本中、供人阅读、不参与执行的纯文本标记，MySQL 完全忽略它们。
-
--开头（注意后面必须有空格），直到行末：-- 这是一条注释 -
#开头（MySQL 特有，也需空格），直到行末：# 仅 MySQL 支持这种写法 -
/* ... */包裹，支持跨行：/* 查询用户+统计，2025-12-29 */
⚠️ 常见错误：写成 --注释（缺空格）或 /*注释*/（无空格），部分客户端（如旧版 Navicat 或某些 CLI 模式）可能报错或截断；// 不是 MySQL 注释语法，会直接报错。
给表和字段加业务注释（COMMENT）的正确姿势
这类注释会写入 information_schema 元数据，被 Navicat、DataGrip、Laravel Schema、甚至部分 ORM 自动生成文档时读取，属于“可编程的注释”。
- 建表时直接加：
CREATE TABLE user ( id INT PRIMARY KEY COMMENT '主键ID', name VARCHAR(50) COMMENT '用户真实姓名' ) COMMENT = '用户基础信息表';
- 修改已有表注释：
ALTER TABLE user COMMENT = '更新后的用户主表'; - 修改字段注释（必须重写字段定义）：
ALTER TABLE user MODIFY COLUMN name VARCHAR(50) COMMENT '用户全名（含姓氏）';
⚠️ 关键陷阱：修改字段注释时，MODIFY COLUMN 后面的字段类型必须和原类型完全一致（包括长度、是否 NULL、DEFAULT 等），否则会意外变更结构。例如原字段是 VARCHAR(50) NOT NULL，就不能只写 VARCHAR(50) COMMENT 'xxx'，漏掉 NOT NULL 会导致该字段变成允许 NULL。
怎么验证注释是否生效
别只信 IDE 界面——有些工具缓存元数据，或不刷新字段注释。最可靠方式是查系统表：
- 查某张表的注释：
SELECT TABLE_COMMENT FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'your_db_name' AND TABLE_NAME = 'user';
- 查某张表所有字段及注释：
SELECT COLUMN_NAME, COLUMN_COMMENT FROM information_schema.COLUMNS WHERE TABLE_SCHEMA = 'your_db_name' AND TABLE_NAME = 'user';
- 快速看完整建表语句（含所有 COMMENT）：
SHOW CREATE TABLE user;
Navicat 右键「设计表」看到的注释，本质也是查的同一套元数据；但如果刚执行完 ALTER 就立刻右键查看却没变，大概率是它没自动刷新，手动 F5 或重新连接即可。
真正容易被忽略的是：COMMENT 内容最长支持 2048 字符（MySQL 5.7+），但很多团队习惯写长段落甚至换行，而 MySQL 实际只存第一行（换行符会被截断或转义）。如果需要结构化描述，建议另建文档关联表名，而不是堆砌 COMMENT。
