CREATE TABLE时直接加COMMENT最省事，字段注释需紧跟类型和约束后、用单引号包裹且转义内部单引号，长度限1024字符；表级注释用comment='xxx'置于语句末尾。
CREATE TABLE 时直接加 COMMENT 最省事
建表阶段就写好字段注释，是最自然、最安全的方式。MySQL 在解析 CREATE TABLE 语句时，只要在字段定义末尾加上 COMMENT 'xxx'，就会一并存入元数据。
注意点：
-
COMMENT必须紧接在字段类型和约束之后，不能换行或隔空格（虽然部分版本容忍空格，但不保险） - 单引号必须成对，内容里有单引号需转义为两个单引号（
''），不要用双引号 - 注释最大长度是 1024 字符，超长会被截断且无警告
- 表级注释用
comment='xxx'放在语句末尾，和字段注释语法独立
示例：
CREATE TABLE orders ( id BIGINT PRIMARY KEY COMMENT '订单唯一ID，全局递增', status TINYINT NOT NULL DEFAULT 1 COMMENT '订单状态：1-待支付,2-已支付,3-已取消', created_at DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间' ) ENGINE=InnoDB COMMENT='核心订单主表';
ALTER TABLE MODIFY COLUMN 更新字段注释要重写完整定义
给已有字段加或改注释，必须用 ALTER TABLE ... MODIFY COLUMN，而且得把字段的**全部属性**原样写出来——类型、是否 NOT NULL、默认值、自增等，漏掉一个可能悄悄删掉约束。
常见翻车场景：
- 原字段是
username VARCHAR(50) NOT NULL DEFAULT ''，只写MODIFY COLUMN username VARCHAR(50) COMMENT '新注释'→NOT NULL和DEFAULT全丢了 - 字段带
AUTO_INCREMENT，但没在MODIFY中声明 → 主键失效或报错 - 用
CHANGE COLUMN改名时只写新名不写类型 → 类型变成TEXT或报错
正确姿势：
ALTER TABLE users MODIFY COLUMN email VARCHAR(100) NOT NULL DEFAULT '' COMMENT '用户注册邮箱，用于登录和通知';
查看字段注释别只靠 SHOW CREATE TABLE
SHOW CREATE TABLE 能看注释，但不适合自动化或批量检查；真正稳定可靠的是查 INFORMATION_SCHEMA.COLUMNS。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
原因：
-
SHOW CREATE TABLE输出是文本格式，字段注释混在 SQL 里，解析麻烦还容易出错 -
COLUMNS.COLUMN_COMMENT是真实字段，可直接WHERE过滤、JOIN关联、导出为 CSV - 某些客户端（如 DBeaver）或 ORM 工具底层就是读这个视图来展示注释
常用查询：
SELECT COLUMN_NAME, COLUMN_COMMENT FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_SCHEMA = 'my_db' AND TABLE_NAME = 'users' AND COLUMN_COMMENT != '';
COMMENT 不参与查询优化，但影响工具链行为
MySQL 自身不会因为字段有 COMMENT 就改变执行计划或索引选择——它纯属元数据，不进存储引擎层。
但它实实在在影响下游工具：
- Navicat / DBeaver 等 GUI 工具会把
COLUMN_COMMENT显示在列备注栏 - MyBatis Generator、JOOQ 等代码生成器默认把注释映射为 Java 字段 Javadoc
- 某些内部文档系统（如 DBSchema）靠它自动产出数据字典 PDF
- 如果注释里写了枚举含义（如
'状态:1-启用,0-禁用'），业务同学查起来就不用翻代码
所以别嫌麻烦——哪怕只写一行「该字段由风控系统写入」，半年后你 debug 时会感谢自己。
