MYSQL UPDATE 在很短的时间内更新相同的语句，就会有告警，导至事务失败，有没有人遇到这问题？

如：UPDATE api_wallet SET credits=credits+'1087.77', cost=cost+'151.23' WHERE uid='12';
Rows matched: 1 Changed: 1 Warnings: 1
mysqli_warning Object
(
[message] => Data truncated for column 'credits' at row 1
[sqlstate] => HY000
[errno] => 1265
)

看看 credits 的定义

不是这个问题呢，所有字段结构是 decimal(16,2)

MYSQL 版本 8.4.0

MYSQL 版本 8.4.5

我猜想是 文本转数字损失精度的问题

如果不是手写的代码 就换个靠谱点的 orm
现在高版本 MYSQL 的默认开启的严格模式可能都没法运行

小数位扩大一下验证试试？

也是 MySQL 8 ，遇到过，同一个事务里多次更新同一条记录的同一个 int 字段报错 (延时一下就不报错了)。

最佳实践是别用 mysql 做算术题，你就当他是 kv 你 update 一个主键就行。

先查出来，加个锁，开个事务，提交数据

mysql 的 cpu 很值钱，你程序的 cpu 不值钱

否则你高频做整个事情 mysql 内部自己有悲观锁什么的不整死你才怪

有没有查过日志，引起警告的语句具体是什么，有没有可能你在有些语句里面，传入了不符合数据库字段需要的值，比如 1087.770

感谢大家回复，我测试看看，谢谢！

告警就是这个 Data truncated for column 'credits' at row 1

credits 没有 not null default ，update 前值为 null ？

不是很明显的溢出问题么? 你先改为 decimal(16,6) 测测

＃9 查出来再加锁？？？😂 事务是这么玩的嘛 干脆不要事务得了

经过测试就是 文本转数字损失精度的问题

第一遍查总得大概齐看下有没有余额吧，完成一些不需要写表的业务逻辑。

至于在事务里面要不要再次查或者 select for update 随你

（我就这么一说不要认真当伪代码了 hhh

复议 9 楼..把这一行的操作逻辑独立出来,轻事务,并加锁

Data truncated for column 'credits' at row 1 你设置的值超过字段精度了

UPDATE api_wallet SET credits=credits+'1087.77', cost=cost+'151.23' WHERE uid='12';
估计是这个值'1087.77' 被转换成 1087.769999999