mysql sql_mode=宽松模式,但出现Data truncation: Data too long for column xxx at row y

本文详细记录了一次在MySQL宽松模式下遇到的数据截断错误的排查过程,包括开启日志查看SQL执行历史,确认更新语句无误,观察是否因其他语句或程序干扰,以及检查服务启动时的sql_mode设置。最终发现是服务启动时预设了会话级别sql_mode为严格模式,导致字段超长时直接报错并回滚。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

目录

1.1 数据库版本

1.2 数据库sql_mode未开启严格模式

2.排查

2.1 开启日志模式,用于查看历史执行sql

2.2 抓取执行sql日志

2.3 观察发现,确实有发送了update的语句,但是最后却发生了rollback

2.4 同时观察该时间范围内是否执行了其他语句

2.5 重启服务观察,是否启动时预设了一些参数

2.6 确认代码位置

2.7 总结


1.1 数据库版本

1.2 数据库sql_mode未开启严格模式

mysql

2.排查

2.1 开启日志模式,用于查看历史执行sql

SET GLOBAL log_output = 'TABLE';SET GLOBAL general_log = 'ON';  //日志开启

2.2 抓取执行sql日志

SELECT * from mysql.general_log where argument <> 'SELECT 1' ORDER BY event_time DESC;

(此处过滤select 1 是因为程序不断尝试通过select 1保持连接可用,所以剔除该项的干扰需要进行过滤)

2.3 观察发现,确实有发送了update的语句,但是最后却发生了rollback

经核对,update语句无误,并且单独拿出执行,能够正常执行成功(但是因为长度超限,同时数据库sql_mode是宽松模式,故update时发生了截断)

2.4 同时观察该时间范围内是否执行了其他语句

- 经观察,期间没有执行其他语句,故排除语句问题、排除其他数据库相关的干扰

- 同时也排除了程序问题(可能大家会怀疑是不是程序额外进行了一些操作,在代码侧进行了校验和阻挡。但是从mysql侧有收到执行请求,故可排除)

2.5 重启服务观察,是否启动时预设了一些参数

发现在连接前确实设置了sql_mode为严格模式

2.6 确认代码位置

mysql-connector-java.jar -> com.mysql.jdbc.initializePropsFromServer -> com.mysql.jdbc.setupServerForTruncationChecks

2.7 总结

服务启动时,已经指明会话级别的sql_mode为严格模式,故字段超长后不会自动截取而是直接报错并回滚

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值