1. 错误现象
更新用户头像时，系统抛出了一个异常，下面来详细分析具体内容：
org.springframework.dao.DataIntegrityViolationException: ### Error updating database. Cause: com.mysql.cj.jdbc.exceptions.MysqlDataTruncation: Data truncation: #22001...SQL: update sys_user set a vatar = ? where user_name = ?
异常的核心是 MysqlDataTruncation，错误码为 #22001，对应的 SQLSTATE 含义是“字符串数据右截断”——简单来说，就是写入的数据过长，无法容纳进目标列。Spring 框架将其包装成了 DataIntegrityViolationException 抛出。
2. 错误码 #22001 的含义
在 MySQL 中，22001 表示字符串截断的警告或错误。官方文档的描述非常直接：
Data too long for column ‘column_name’
当插入或更新的字符串长度超出列定义的最大长度（例如 VARCHAR(255)）时，如果数据库启用了严格 SQL 模式（STRICT_TRANS_TABLES），就会直接拒绝写入并抛出错误。若未开启严格模式，数据会被静默截断，仅产生一个警告——这可能导致数据在不知不觉中丢失，存在较大隐患。
3. 常见触发场景
该错误出现在 a vatar 字段上，通常离不开以下几种情况：
- 存储 Base64 编码的图片：将图像直接转换为 Base64 字符串存入数据库。一张 100KB 的图片，Base64 编码后长度大约在 13 万字符左右，远远超出
VARCHAR(255)的容量，必然引发报错。 - 存储过长的 URL：部分头像 URL 包含大量参数和签名，长度可能超过预设值，同样容易触发问题。
- 列定义长度不足：表结构设计时未充分考虑实际数据的长度分布，默认使用了较小的
VARCHAR长度，用户上传头像时便会出错。
4. 定位方法
4.1 查看表结构
执行以下命令，确认字段类型和长度：
DESC sys_user;
如果 a vatar 定义为 varchar(255) 或类似的短长度类型，基本可以锁定原因。
4.2 输出待写入数据的长度
在应用代码中临时记录数据长度，例如：
String a vatarData = getUserA vatarData();logger.debug("a vatar data length: {}", a vatarData.length());将该长度与列定义的最大长度进行对比，即可判断是否为数据过长导致的问题。
4.3 检查 SQL 模式
SELECT @@sql_mode;
如果结果中包含 STRICT_TRANS_TABLES，写入超长数据时就会直接报错；否则可能仅产生警告并悄悄截断数据。
5. 解决方案
根据业务需求选择合适的方式进行处理。
5.1 扩大列长度（适用于临时存储 Base64 的场景）
如果业务上暂时必须将头像 Base64 字符串存入数据库，可以将列类型改为能容纳更大文本的类型，例如：
ALTER TABLE sys_user MODIFY COLUMN a vatar MEDIUMTEXT;
各文本类型的存储容量如下：
TEXT：最大 65,535 字节（约 64KB）MEDIUMTEXT：最大 16,777,215 字节（约 16MB）LONGTEXT：最大 4,294,967,295 字节（约 4GB）
通常 MEDIUMTEXT 即可覆盖绝大多数 Base64 头像。需要注意的是，将大文本存储在数据库主表中会影响查询性能，应尽量避免在频繁查询中使用 SELECT *。
5.2 存储文件路径或 URL（推荐方式）
更合理的设计是：数据库只保存头像文件的访问路径，文件本身交给对象存储或专用文件系统管理。
实施步骤：
先修改表结构，将 a vatar 字段改为存储 URL 的合适长度：
ALTER TABLE sys_user MODIFY COLUMN a vatar VARCHAR(500) DEFAULT NULL COMMENT '头像URL';
然后修改应用逻辑：接收头像文件后，上传到对象存储服务（例如 OSS、MinIO），获取可访问的 URL，再将该 URL 写入数据库。
更新对应代码：
String a vatarUrl = uploadToOss(file);user.setA vatar(a vatarUrl);sysUserMapper.updateUserA vatar(user);
该方案的优势十分明显：
- 数据库字段长度固定且较小，不会出现截断风险。
- 图片可以独立进行 CDN 加速和访问控制。
- 数据库体积可控，备份和恢复效率更高。
5.3 应用层限制图片大小（辅助措施）
如果确实需要保存 Base64 数据，可以在存入前对图片进行压缩和尺寸限制，以减小字符串长度。例如使用 Thumbnails 库：
byte[] compressed = Thumbnails.of(inputStream) .size(128, 128) .outputQuality(0.5) .asByteArray();String base64 = Base64.getEncoder().encodeToString(compressed);
该方法只能减少数据量，最好还是结合 5.1 方案扩大列长度，并为未来数据增长留出余量。
6. 预防措施
数据库设计规范
避免在常规业务表中使用大文本类型存储文件内容。若必须存储长文本，可考虑垂直拆分到独立表，减少对主表查询的影响。
应用层校验
在数据写入前增加长度校验，给出明确的业务错误提示：
if (a vatar != null && a vatar.length() > 500) { throw new BusinessException("头像地址长度超出限制");}严格 SQL 模式
生产环境建议启用 STRICT_TRANS_TABLES，让异常尽早暴露，避免数据静默丢失。
监控与日志
对 DataIntegrityViolationException 进行监控告警，记录完整的数据长度和表信息，方便快速定位问题。
7. 总结
Data truncation: #22001 错误的直接原因是写入数据长度超过了列定义上限。但深入分析后会发现，根本问题在于数据库字段设计未能与数据类型良好匹配。将非结构化大文本（例如 Base64 图片）存入数据库，会带来性能和维护的双重负担。推荐采用“数据库存储路径 + 对象存储保存文件”的架构。如果确实无法改变存储方式，则合理选择 TEXT/MEDIUMTEXT 类型，并配合应用层校验，确保数据完整性和系统稳定性。
