VARCHAR(255)在utf8mb4下建索引会报错，因InnoDB单列索引上限767字节，而255×4=1020字节超限；即使启用innodb_large_prefix，过长前缀仍拖慢写入、降低缓冲池命中率，且唯一索引仅校验前缀易导致逻辑重复。
MySQL中VARCHAR长度不建议盲目设为255，核心问题不在存储本身，而在索引创建失败、内存表膨胀和区分度浪费这三个实际场景里。
为什么VARCHAR(255)在utf8mb4下建索引会报错
InnoDB默认单列索引长度上限是767字节。utf8mb4下每个中文或emoji占4字节，VARCHAR(255)理论最大需1020字节 → 超限。错误信息是：Specified key was too long; max key length is 767 bytes。这不是配置没开，是引擎硬限制。
- 即使启用
innodb_large_prefix=ON，上限提至3072字节，但过长前缀仍拖慢写入、降低缓冲池命中率 - 唯一索引只校验前缀部分，
email VARCHAR(255)建UNIQUE(email)可能漏掉后缀差异，导致逻辑重复 - 真实区分度往往集中在前30–100字符，比如邮箱域名部分就决定了99%的唯一性
VARCHAR(50)和VARCHAR(255)在InnoDB里存储开销真的一样吗
是的，只要长度≤255，InnoDB都用1字节存长度字段；超过255（如VARCHAR(256)）才升为2字节 —— 这会导致ALTER TABLE重建整张表。但“一样”仅限于磁盘存储，内存使用完全不是一回事。
- 查询中间结果（如GROUP BY、ORDER BY、临时表）会转成内存表（
MEMORY引擎），它按定义长度预分配空间 -
VARCHAR(255)在utf8mb4下，内存表每行按2 + 4×255 = 1022字节算；VARCHAR(50)则只需2 + 4×50 = 202字节 - 1万行数据，单字段就能差出8MB内存 —— 这在OLAP类查询或JOIN多表时极易触发
Unable to allocate memory
怎么确定一个字段该用VARCHAR(XX)而不是拍脑袋定255
先看用途：是否建索引？是否参与排序/分组？是否进临时表？再查真实数据分布，而不是凭经验。
- 查最长实际值：
SELECT MAX(LENGTH(email)) FROM users;，再加20%余量 - 验证前缀区分度：
SELECT COUNT(DISTINCT LEFT(email, 60)) / COUNT(*) AS selectivity FROM users;，>0.95就足够 - 固定格式字段直接卡死长度：
sku VARCHAR(20)、phone VARCHAR(15)、iso_code CHAR(2) - 描述类字段超过500字符，优先考虑
TEXT，避免行溢出和锁升级风险
真正容易被忽略的不是“能不能设255”，而是开发阶段没人去跑EXPLAIN FORMAT=TREE看是否用了内存表，也没人定期查SHOW STATUS LIKE 'Created_tmp%';——这些指标一飙高，VARCHAR长度问题就从设计隐患变成线上抖动根源。
