不是超过255就该换TEXT，而需综合字符集、行总长限制（65535字节）、页内非溢出部分上限（8126字节）、查询需求及存储开销判断；utf8mb4下VARCHAR(1000)最多占4000字节+长度头，易触发Row size too large错误。
建表时字段长度超 255 就该考虑 TEXT？别急，先看真实限制
不是“超过 255 就换 text”，而是要看你存的是什么、怎么查、会不会排序或 group by。varchar(1000) 在 utf8mb4 下理论最大占 4000 字节（每个汉字 4 字节），加上其他字段和 mysql 行头开销，很容易触碰 row size too large 这个硬限制。navicat 在保存前会静态估算整行大小，一旦预估超 65535 字节，就直接禁用保存按钮——这不是 bug，是提前拦住 mysql 内核报错。
实操建议：
- 纯短文本（用户名、地址、标签名等 ≤ 255 字符）：优先用
VARCHAR，索引友好，查询快 - 可能存几百字符以上、且不常参与 WHERE 条件或 ORDER BY 的字段（如用户反馈、日志摘要）：直接选
TEXT，避开行大小陷阱 - 字段内容带换行、HTML 片段、JSON 片段但长度不确定：别硬撑
VARCHAR(65535)，MySQL 不允许单字段占满整行，TEXT更稳妥
TEXT 字段不能设 DEFAULT 值？MySQL 8.0.13+ 是个例外
Navicat 设计界面里把字段类型切到 TEXT 后，“长度”输入框自动变灰，这是对的——TEXT 本身无长度参数。但很多人接着点保存，发现 NOT NULL 字段没默认值，插入时报错 Field 'xxx' doesn't have a default value。
原因在于：TEXT 类型在 MySQL 8.0.13 之前确实不支持传统 DEFAULT 值（比如 DEFAULT ''），Navicat 也不会帮你补。8.0.13+ 起支持表达式默认值（如 DEFAULT ( '')），但 Navicat UI 不暴露这个选项，必须手写 DDL。
实操建议：
- 若用 MySQL NULL，或业务层保证必填
- 若用 MySQL ≥ 8.0.13：在 Navicat 执行查询窗口运行
ALTER TABLE t MODIFY content TEXT DEFAULT ('');，不要依赖 UI 补默认值 - 别在 Navicat 表设计器里对
TEXT字段填“默认值”框——它不会生效，还可能误导
迁移时 TEXT 被转成 VARCHAR(255)？检查 Field Mapping 是否启用
从 MySQL 迁到 PostgreSQL 或 SQL Server 时，Navicat 默认把 TEXT 映射成 CHARACTER VARYING(255) 或 NVARCHAR(MAX)，而不是目标库原生的 TEXT 类型。这不是映射错了，是你没进具体任务里开定制开关。
关键路径是：数据传输 → 源与目标页面 → 右下角「高级」按钮 → Field Mapping 标签页，不是顶部菜单的「选项」。
实操建议：
- 务必勾选
Enable field type mapping，否则下面规则全无效 - 点击
Add手动加规则：Source Type = TEXT→Target Type = TEXT（别信下拉推荐值） - 如果源是
VARCHAR(5000)，目标 PostgreSQL 不支持长度，Navicat 可能静默 fallback 到character varying(255)，此时必须显式配VARCHAR → TEXT规则
TEXT 字段加索引只能前缀？那 255 就是常见临界点
TEXT 字段不能像 VARCHAR 那样整列建索引，必须指定前缀长度，比如 INDEX(content(255))。这个数字不是随便写的——太小（如 50）可能无法区分相似长文本；太大（如 1000）会让索引体积暴涨，尤其字段实际内容平均就 200 字符时。
性能影响很实在：用 ORDER BY content 或 GROUP BY content 会强制走基于磁盘的临时表，MEMORY 引擎直接退避。
实操建议：
- 只对真正需要检索前 N 个字符的场景建前缀索引，比如搜索文章标题片段、URL 前缀
- 确认业务查询是否真依赖
content LIKE '%xxx%'——这种没法用索引，不如改用全文索引或外部搜索引擎 - 如果字段经常用于
WHERE content = ?，且值较短（≤ 500 字符），回退用VARCHAR(500)+ 整列索引，比TEXT+ 前缀索引更高效
