mysql 8.0严格模式下超字节必报错1406，需按utf8mb4字节上限（如varchar(255)为1020字节）校验，分层检查字段定义、连接编码、应用层getbytes长度及行总限制，并验证text实际容量。
MySQL 8.0 默认开启严格模式（STRICT_TRANS_TABLES），只要数据字节长度超过字段定义的**实际字节容量**，就会直接报错 Data too long for column（错误码 1406）——不是警告，是中断写入。不能靠“试试看”或“客户端显示正常”来判断，必须按字节算、分层查。
先确认字段真实字节上限，别只看 VARCHAR(n)
比如 VARCHAR(255) 在 utf8mb4 下最多存 255 个字符，但每个字符最多占 4 字节，所以实际字节上限是 255 × 4 = 1020 字节。而 TEXT 类型限制的是总字节数（65535），不是字符数。
- 执行
DESCRIBE table_name;看字段类型和长度 - 执行
SHOW CREATE TABLE table_name;确认该列是否显式指定了CHARSET和COLLATE；哪怕表默认是utf8mb4，单列也可能被建为latin1或旧版utf8 - 查现存数据最大字节长度：
SELECT MAX(LENGTH(column_name)) FROM table_name;—— 结果必须 ≤ 你计划设的新长度（单位：字节）
检查连接层编码是否一致，否则字节会“凭空变长”
同一个字符串，在不同连接编码下 LENGTH() 返回值可能差一倍。例如 SQL 文件是 UTF-8 编码，但命令行没加 --default-character-set=utf8mb4，MySQL 就按服务器默认（如 latin1）解析，导致中文被错误解码成乱码字节流，触发超限。
- 查当前 session 编码：
SELECT @@character_set_client, @@character_set_connection, @@character_set_results; - Java 应用 JDBC URL 必须带：
?characterEncoding=utf8mb4&useUnicode=true - 命令行导入时强制指定：
mysql -u root -p --default-character-set=utf8mb4 database_name - 应用层校验必须用字节长度：
value.getBytes(StandardCharsets.UTF_8).length ，而不是 <code>value.length()
改字段前先看索引和行限制，不然 ALTER 了也白改
ALTER TABLE ... MODIFY COLUMN 只改定义，不清理历史数据，也不自动同步索引。常见翻车点：
- 字段已被建为前缀索引（
SHOW INDEX FROM table_name WHERE Column_name = 'xxx';中Sub_part > 0）→ 需同步重建索引：DROP INDEX idx_name ON table_name; CREATE INDEX idx_name ON table_name (column_name(1024)); - 整行总字节数不能超 65535（InnoDB 行格式限制）→ 如果把多个
VARCHAR都扩到几百，可能撑爆单行，此时应优先换TEXT - ORM 模型（如 SQLAlchemy）缓存了旧 schema → 改完 DB 还要同步改模型定义，比如把
Column(String(255))改成Column(String(1024))或Column(Text)
TEXT 不等于“永不报错”，超 65535 字节照样失败
很多人以为换成 TEXT 就一劳永逸，其实 TEXT 的硬限制仍是 65535 字节（不含行头开销）。含大量 emoji、base64 或富文本字段很容易踩中。
- 验证是否真超限：
SELECT LENGTH(column_name) FROM table_name ORDER BY LENGTH(column_name) DESC LIMIT 1; - 若接近或超过 65535，考虑拆字段、压缩内容（如 gzip 后 base64）、或改用
MEDIUMTEXT（最大 16MB） - 注意：
MEDIUMTEXT要求innodb_file_format = Barracuda且表使用ROW_FORMAT=DYNAMIC或COMPRESSED
最常被忽略的其实是四层编码一致性：表定义、列定义、连接 client、应用层字节计算。少一层对齐，就可能在测试环境跑通、上线后随机报错。别只盯着 ALTER TABLE，先跑完那三条 SELECT 和一条 SHOW。
