直接改字段长度不一定能解决问题，需先确认是字符数、字节数、索引前缀或计算过程导致超限；utf8mb4下emoji等补充平面字符占4字节，mysql校验依据是length()返回的字节数而非char_length()字符数，且索引前缀、连接编码、单行总长65535字节限制及group by内存溢出均可能引发该错误。
直接改字段长度不一定能解决问题，得先确认是字符数超限、字节数超限，还是索引前缀或计算过程卡住——很多“Data too long”报错根本不是字段太小，而是 utf8mb4 下一个 emoji 就占 4 字节，或者 GROUP BY 时哈希键撑爆内存。
查清真实字节数，别信字符数
中文、emoji、生僻字在 utf8mb4 下不是都占 3 字节；?、?? 这类补充平面字符占 4 字节。用 CHAR_LENGTH() 看的是字符个数，但 MySQL 校验长度用的是字节数：LENGTH() 才是关键。
- 执行
SELECT LENGTH('测试'), LENGTH('??'), LENGTH('abc');—— 结果分别是 6、4、3（utf8mb4 环境下） - 若字段是
VARCHAR(100)，插入含 26 个 emoji 的字符串，CHAR_LENGTH()是 26，但LENGTH()可能达 104+，直接超限 - 应用层截断必须按字节：Python 用
value.encode('utf8')[:max_bytes]，不是value[:max_chars]
检查字段是否被索引拖累
哪怕你把 VARCHAR(255) 改成 VARCHAR(500)，只要该字段上有索引且是前缀索引（比如 INDEX(name(50))），插入时仍可能因唯一性校验或排序逻辑失败而报错。
- 查索引：运行
SHOW INDEX FROM table_name WHERE Column_name = 'column_name';，看Sub_part是否大于 0 - 前缀索引不等于字段长度上限——它只影响索引结构，不影响存储，但会干扰 INSERT/UPDATE 的完整性检查
- 若需完整值参与唯一约束，必须删旧索引、重建全字段索引：
DROP INDEX idx_name ON table_name; CREATE INDEX idx_name ON table_name (column_name);
ALTER TABLE 后还报错？三件事立刻验证
改完字段长度却继续报错，大概率是旧数据、连接编码、或单行总长限制在作祟。
- 查现存最长字节数：
SELECT MAX(LENGTH(column_name)) FROM table_name;—— 结果必须 ≤ 新设长度 × 每字符最大字节数（utf8mb4 是 ×4） - 查连接字符集：
SELECT @@character_set_client, @@collation_connection;—— 若为utf8（非utf8mb4），客户端发来的 emoji 会被错误解码，字节数翻倍 - 算单行总字节数上限：MySQL 单行不能超 65535 字节，
VARCHAR(500)在 utf8mb4 下最多占 2000 字节，但若表里还有十几个类似字段，加起来就容易撞墙
聚合查询报 Data too long？别急着改字段
在 GROUP BY 或 ORDER BY 中用长文本字段，错误常来自内存哈希桶或排序缓冲区溢出，和字段定义无关。
- PostgreSQL 报错带
Hash Key或external merge disk，说明是计算层瓶颈，不是存储层 - MySQL 的
GROUP_CONCAT默认上限 1024 字符，要先设SET SESSION group_concat_max_len = 1000000; - 真正安全的做法是聚合前截断：
GROUP BY SUBSTRING(description, 1, 255)，并确保该长度 ≤ 字段定义的字符数（不是字节数）
最容易被忽略的是：同一个字段，在不同 session 的 character_set_client 下，LENGTH() 返回值完全不同；而报错永远以当前 session 编码为准——没锁死 client/table/column 四层字符集一致性，光调大字段只是临时糊墙。
