User u = userMapper.selectOne(id);
u.setName(myname);
u.setAge(myAge);
userMapper.updateById(u);

我看工作里面很多代码都是这样更新的，虽然方便但是有并发问题，大佬们 cr 遇到会打回去吗？

看场景，订单这样去更新要被批。
用户这样更无所谓。

绝对不允许。

并发问题，建议加上乐观锁

不懂 java ，但为啥这样会有并发问题？按我的理解 u 是 select 返回的，updateById 的过程才会创建 transaction 并 commit ，理论上 u 不共享不会出并发问题？

＃4 第一个请求还没完成的时候第二个请求进来了, 由于一些原因导致第二个请求比第一个快, 最后的结果就变成了保存第一个请求的值

我也不懂 java ，但是我觉得如果在 select 和 update 之间 user 的某一项数据更新了，会被 update 覆盖

大佬

看场景，没要求的位置这么写没问题，写完赶紧下班。有要求的位置简单加一个事务，赶紧下班。对性能有影响了？那就改为乐观锁，改完下班。

所以你们的每个表都有类似 version 字段的东西么，实践中很少这样吧，我看到的绝大部分更新都是这样更的。

理论上最好每次只更新自己的字段，但是那样写真的很麻烦吧。要通用的话你就得改造你的 DO ，让他能检测自己被改变了什么字段。

真要说起来，这才是“正确”的（或者说是现代的）写法，前提是有乐观锁或者分布式锁

业务系统用数据库事务来做并发控制是个很不好的做法

参考 DDD 中的 repository 和 unit of work 模式

martinfowler.com/eaaCatalog/repository.html
martinfowler.com/eaaCatalog/unitOfWork.html

用户资料（姓名、年龄）不就是他自己一个人会更改吗？应该不会有并发问题。

并发你这后端改了也没啥用

实际上最有可能出现的并发问题不在这两行之间。而是前端的问题
比如
1 、甲打开了网页，拿到了 a 和 b 和两个字段，然后就去忙别的去了
2 、乙也打开了网页，拿到了 a 和 b ，然后把 b 修改成 b1 ，接着把 a 和 b1 一起提交上去
3 、甲回来了，把 a 修改成了 a1 ，然后把 a1 和 b 一起提交上去了
4 、最终就输 a1 和 b ，b1 的修改丢失了

正常前端都不会只传变更了的字段，而是偷懒一股脑都传上来
所以你后端其实根本判断不了

不过这其实也没啥大问题，因为通常来说一个表单的正确性就是取决于最后修改他的人而已
既然最后修改他的人觉得没问题，那其实也确实没啥大问题

会出现你更你的我更我的，大家的原始数据都一样，先更的被后更的还原。

首先，一般没有 CR ，提了测了上了完事
然后，除非并发问题会造成生命财产损失或者大量用户投诉，否则无需在意，更何况是一些并发极少的场景

不懂 JAVA
要么先开事务，要么条件里带上原来的值，保证绝对更新

select for update 行锁

楼主是想问，patch or update 吧，java 一般都是全字段更新（过滤 0 值）。
最好是 new 对象，set 对应值，而不是 select by Id ，然后 set 。
不过，无并发冲突，两种都没问题。
但是如果有并发，两种都有问题，都得加锁。

我想了一下，这样的问题除了给数据加上版本号貌似没什么特别好的处理办法了
我觉得还是得看业务，如果这个数据多人共享且并发两很高，那必须加锁
如果没这个需求应该无所谓

严格来说这样是有问题的。
比如你这个场景 1 逻辑是修改了 name,age 。如果另外的场景 2 是修改用户的 phone,并且 phone 修改在前，那么这个 phone 的修改会被场景 1 的旧 phone 覆盖。

以面向对象的思维来说一般都是这么写的。因为往往在实际业务中你把对象 select 出来除了赋值可能还会做很多业务逻辑和计算，完了就将整个对象 update 。如果在要求比较高的场景下，要解决并发问题就通过分布式锁来处理。

当然假如只是单纯更新数据的场景，这种写法并不好，因为可能只要更新一个字段却执行了两个 sql ，甚至把所有字段都更新了一遍，效率比较低，也存在你说的并发问题。所以简单的更新数据比较建议直接通过一句简单的 update 更新。

分场景呢，如果真的并发高那就加锁，要么乐观锁 version 字段，要么加分布式锁，按理说，用户不会天天修改自己的用户信息。

严格来说，不加锁的更新都有可能出你说的问题。加锁带来的问题是性能下降，和用户交互不友好。
但这个问题可以通过业务规则规避，只允许一个用户修改数据就啥问题都没了。

没啥 大影响 ..很多代码这么写的,虽然新开一个 userForUpdate 类会清淅一点
并不并发的,没区别,就算你只更新你的,并发你不加锁,开不开新类也控制不了
对于阿里/腾讯 这类优化过的 mysql,会自动过滤不需要更新的字段,对性能影响也不大

所以，问题出在 mapper 的 updatebyid 并不会像符合认知的 orm 行为那样，只修改自己变更过的字段。而是会 update 整个对象除了 ID 外所有的字段。

对不熟悉的人来说，这个还挺隐蔽的，但是想必已经是 java 生态内的常识了吧。

只更新需要更新的字段，全部更新没意义，重新 new 个对象更新

spring data jpa 中可以给实体加个 就能自动处理乐观缩，这种方式没有毛病，只有更新的一瞬间判断，感觉效率比行锁高。

那怎么写才正确呢 🤣 每个更新操作都考虑并发么

ef 使用 ChangeTracker 跟踪状态变化 只会更新变化的字段
java 的 orm 不清楚是否支持

除非需要事务， 不然我觉得这就是最好的选择。

局部变量这样写 没事吧

查询是不是多余了

如果你用 C＃ ef orm ，官方就是推荐这么写的，但是 ef 自带乐观锁支持和 patch 更新，改了什么字段就更新什么字段

这是 mysql 经典的丢失更新问题，举个相似例子，a 用户读取 user1 时 age=0 并修改 age=age+1=1 ，b 用户读取 user1 时 age=0 并修改 age=age+2=2 ，此时丢失了 a 用户的修改，中间其实更新了+1 ，所以处理时如果要满足场景你在读前就要加锁

某些场景下，绝对允许；
某些场景下，绝对不允许；
某些场景下，无所屌谓；
所以，你是哪个场景？

使用乐观锁更新的话，如果出现了并发有概率出现部分用户无法更新成功的情况，也就是数据库返回受影响行数为 0 ，这个时候需要提示用户修改失败，并要求重新刷新表单数据之后重新提交修改，并发量大的情况下，用户仍然有可能第二次提交也是失败的

使用锁的话，大概率是可以更新成功的，但可能遇到的问题有，并发量大时可能会等待，表现为用户提交表单等待的时间会长一点或者直接等待超时（这种情况下，有可能修改成功，也可能失败）。此外还有一个问题是，后提交的用户有可能会把之前提前的信息给覆盖掉（比如 ＃13 提到的问题）

如果按照锁升级策略来看的话，是否可以考虑如下策略
默认使用乐观锁，当出现冲突时，也就是数据库返回受影响行数为 0 时，进入重锁模式，重锁模式释放完毕之后，再做一个判断，如果当前没有使用资源的线程，则切换回乐观锁模式

用 MP 的 LambdaUpdateWrapper ，只更新指定字段

没并发问题吧, 这里只是用了一个比较蠢的办法去构造了 User u 而已.

为啥不按需更新？

User u= new User();
u.setId(id);
u.setName(myname);
u.setAge(myAge);
userMapper.updateById(u);