Data too long 错误本质是严格模式下字段长度不足导致的校验失败，需同步解决字段容量与SQL执行行为：先查现存数据最大长度、索引前缀及字符集影响，再调整字段或改用TEXT类型，禁用严格模式仅限临时调试。
Data too long for column 错误本质是 MySQL 拒绝写入超出字段定义长度的数据，不是数据损坏，也不是权限问题，而是严格模式（STRICT_TRANS_TABLES 或 STRICT_ALL_TABLES）下触发的校验失败。解决它必须同时处理「字段容量」和「SQL 执行行为」两个层面。
为什么 ALTER TABLE MODIFY COLUMN 后还报错
常见错觉：改了 VARCHAR(50) 到 VARCHAR(200) 就万事大吉。但实际可能：
- 表里已有超长数据（比如原字段存了 180 字符，你只扩到 200，但新业务要插 250 字符），
MODIFY不会自动截断或清理旧数据，只是放宽上限 - 字段带索引且是前缀索引（如
INDEX(username(50))），即使字段本身扩到 200，索引仍只覆盖前 50 字符，INSERT 时若唯一性冲突或排序逻辑依赖完整值，仍可能间接引发异常 - 应用层 ORM（如 Laravel Eloquent、Django ORM）缓存了旧的表结构元信息，没重载 schema，导致生成的 INSERT 语句仍按旧长度预分配参数
修改字段长度必须确认的三件事
执行 ALTER TABLE table_name MODIFY COLUMN column_name VARCHAR(255) 前，先跑这三条检查：
- 查最长现存数据：
SELECT MAX(LENGTH(column_name)) FROM table_name;—— 结果必须 ≤ 你设的新长度 - 查是否被索引约束：
SHOW INDEX FROM table_name WHERE Column_name = 'column_name';—— 若有Sub_part > 0，说明是前缀索引，需同步调整索引：DROP INDEX idx_name ON table_name; CREATE INDEX idx_name ON table_name (column_name(255)); - 查字符集影响：
SHOW CREATE TABLE table_name;看该字段用的是utf8mb4吗？如果是，VARCHAR(255)实际最多占 255 × 4 = 1020 字节，而单行总长不能超 65535 字节（Server 层限制），别为了扩一个字段把整行撑爆
临时绕过 Data too long 的危险操作
仅限调试或紧急修复，不可上生产：
- 关严格模式（立刻生效，会静默截断）：
SET SESSION sql_mode = '';或SET SESSION sql_mode = (SELECT REPLACE(@@sql_mode,'STRICT_TRANS_TABLES','')); - 但注意：
INSERT INTO ... VALUES (...)在非严格模式下对超长VARCHAR会截断并警告（Warning: Data truncated for column 'xxx'），而TEXT类型字段不受此截断影响，所以有时换类型比扩长度更稳 - 真正安全的“绕过”是改应用逻辑：在入库前用
SUBSTRING(value, 1, 255)截断，而不是依赖数据库兜底
DECIMAL 和 INT 类型的长度陷阱
DECIMAL(10,2) 和 INT(11) 的括号数字意义完全不同，扩错就白忙：
-
DECIMAL(M,D)：M 是总位数，D 是小数位数。想存 999999.99 必须设DECIMAL(8,2)，不是DECIMAL(10,2)—— 多出来的两位会被当整数位浪费，反而挤占可用范围 -
INT(M)的 M 仅控制显示宽度（配合ZEROFILL），不影响存储范围。扩INT(10)到INT(11)完全无意义，INT永远是 4 字节，范围固定在 -2147483648 ~ 2147483647 - 真要扩大数值范围，得换类型：
INT→BIGINT，或DECIMAL(10,2)→DECIMAL(15,2)
最常被忽略的是：字段长度调大后，如果表使用 COMPACT 行格式且含多个可变长字段，可能导致页内碎片加剧，批量 INSERT 性能反而下降——建议扩完长度后执行 OPTIMIZE TABLE table_name; 重建聚簇索引。
