优先选TEXT，因大字段超65535字节限制时VARCHAR易触发行大小错误；TEXT支持FULLTEXT索引和前缀索引，适合模糊查询；频繁排序分组且长度稳定≤500字符用VARCHAR更高效；MySQL 5.7+ DYNAMIC格式下存储差异缩小，但语义约束不同。
大字段存储选 TEXT 还是 VARCHAR，关键看数据长度是否稳定、是否需要索引、是否参与排序/分组，以及所用 MySQL 版本。
数据长度是否超过 65535 字节
MySQL 单行最大限制约 65535 字节（实际略小，含其他字段开销）。如果单条记录中所有列总长度可能超限，大字段必须用 TEXT 类型（如 TINYTEXT、TEXT、MEDIUMTEXT、LONGTEXT），因为 TEXT 不计入行内长度限制，只存指针；而 VARCHAR(n) 的 n 是字符数，但其字节占用会参与行长度计算，容易触发 “Row size too large” 错误。
- 例如：定义 10 个 VARCHAR(8000) 字段，在 utf8mb4 下每个最多占 4×8000=32000 字节，仅两个就超限
- 改用 MEDIUMTEXT 后，每字段只占 3 字节指针，大幅降低行内压力
是否需要前缀索引或全文检索
TEXT 支持前缀索引（如 INDEX(content(255)）和 FULLTEXT 索引，适合日志、文章正文等模糊查询场景；VARCHAR 虽也能建前缀索引，但若长度设得过大（如 VARCHAR(10000)），索引本身会很重，且无法建 FULLTEXT（除非显式指定长度 ≤ 3072 字节且满足 ft_min_word_len 等条件）。
- 想对长文本做 LIKE '%关键词%' 或 MATCH...AGAINST 查询 → 优先 TEXT + FULLTEXT
- 只查开头固定格式（如 JSON 前缀校验）→ VARCHAR(255) + 前缀索引更轻量
是否频繁更新或涉及排序/分组
VARCHAR 存在行内，读取快，适合中小长度且常被 SELECT 或 ORDER BY / GROUP BY 使用的字段；TEXT 默认存于行外，每次访问需额外 IO，排序分组时还可能触发磁盘临时表（尤其是 sort_buffer_size 不足时）。
- 用户简介、商品短描述（≤ 500 字符）→ VARCHAR(500) 更合适
- 评论内容、API 响应快照、Markdown 文档 → TEXT 更稳妥，避免锁表和复制延迟
MySQL 版本与行格式影响
MySQL 5.7+ 使用 DYNAMIC 或 COMPRESSED 行格式时，VARCHAR 超过约 255 字节也会自动转为行外存储（类似 TEXT），此时二者物理存储差异缩小；但语义上仍有区别：VARCHAR 有长度约束、支持 DEFAULT 值、可为 NULL 或 NOT NULL 更灵活，TEXT 则强制允许 NULL 且不能设 DEFAULT（除非用触发器或应用层兜底）。
- 新项目建议统一用 DYNAMIC 行格式（innodb_file_format= Barracuda + innodb_file_per_table=ON）
- 若需 DEFAULT '...' 或严格长度校验 → 选 VARCHAR；若纯内容容器、长度不可控 → 选 TEXT
不复杂但容易忽略：别只看“能存多长”，要结合查询模式、写入频率、运维成本一起判断。多数业务里，500 字以内用 VARCHAR，1K 以上倾向 TEXT，中间地带按实际 SQL 慢日志和执行计划调优。
