MySQL字段COMMENT长度超限会直接报错中断，最大允许1024字符，超出部分静默截断；旧版本或特定配置下可能在解析阶段即报“Comment for column 'xxx' is too long”，而5.7+虽更宽松但仍受此限。
MySQL字段COMMENT长度超限会直接报错中断DDL
字段注释最大允许 1024 字符，超出部分会被静默截断——但这是在 CREATE TABLE 或 ALTER TABLE MODIFY COLUMN 执行成功后才发生的。真正导致DDL失败的，是某些旧版本（如 MySQL 5.6 之前）或特定配置下对注释长度的硬性校验。更常见的是：你写了超长注释，MySQL 在解析建表语句时就直接报错，不进执行阶段。
典型错误信息是：ERROR 1071 (42000): Specified key was too long; max key length is 3072 bytes——别被这个误导，它常和注释无关；而字段注释过长的真实报错更可能是：Comment for column 'xxx' is too long（注意不是表级注释的 max = 110 错误）。
- MySQL 5.7+ 对字段注释长度检查更宽松，但超
1024字符仍会截断，且不提示 - 用
LENGTH('中文注释')测字节数，UTF8MB4 下一个汉字占 4 字节，1024字符 ≈256个汉字就到顶 -
SHOW CREATE TABLE看到的注释是“看起来正常”的，但查INFORMATION_SCHEMA.COLUMNS.COLUMN_COMMENT才是真实存进去的内容
ALTER TABLE MODIFY COLUMN 改注释时，超长注释会放大操作风险
改已有字段注释必须重写整个字段定义，比如 MODIFY COLUMN name VARCHAR(50) NOT NULL DEFAULT '' COMMENT '新注释'。这时如果注释内容过长，虽然 MySQL 可能只截断注释，但你手写语句时容易因字符过多导致格式错乱、漏写约束，结果把 NOT NULL 或默认值悄悄丢了。
- 漏写
AUTO_INCREMENT→ 主键失效，插入报错ERROR 1067 (42000): Invalid default value - 漏写
DEFAULT→ 字段变成NULL，业务层判空逻辑可能崩 - 注释太长让整条
ALTER语句难以 review，人工核对成本陡增
表注释和字段注释的长度限制完全不同，别混用
表级注释（COMMENT='xxx'）在 MySQL 5.7+ 是 2048 字节上限，而字段注释始终是 1024 字符上限——注意单位不同：一个是字节，一个是字符。老版本（如 2010 年资料提到的）甚至把表注释限制压到 110 字符，遇到就报 Comment for table 't1' is too long (max = 110)。
- 查表注释真实长度：
SELECT LENGTH(TABLE_COMMENT) FROM information_schema.TABLES WHERE TABLE_NAME = 't1' - 查字段注释真实长度：
SELECT LENGTH(COLUMN_COMMENT) FROM information_schema.COLUMNS WHERE TABLE_NAME = 't1' AND COLUMN_NAME = 'name' - 别在注释里塞 JSON、URL 或大段说明，那是文档的事，不是元数据字段该干的
在线 DDL 模式下，注释修改本身不锁表，但语句写错会触发重建
MySQL 5.6+ 的 ALTER TABLE ... MODIFY COLUMN 如果只是改注释，属于 instant DDL，不拷贝数据、不锁表。但一旦你因为注释太长导致语句写错（比如类型写成 TEXT、漏了 NOT NULL），MySQL 可能 fallback 到 COPY 模式，全表重建，锁表数小时。
- 确认是否走 instant 模式：执行后看
SHOW ENGINE INNODB STATUS里的DDL log部分 - 生产环境改注释前，先在测试库跑
EXPLAIN FORMAT=JSON ALTER TABLE ...（5.7+ 支持），看alter_algorithm是INSTANT还是COPY - 字段注释这事，建表时一次写对最省心；事后补，宁可分两步：先加个短注释，再用应用层文档补全说明
