update 大家会允许这样写吗？

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

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

并发你这后端改了也没啥用 实际上最有可能出现的并发问题不在这两行之间。而是前端的问题 比如 1 、甲打开了网页，拿到了 a 和 b 和两个字段，然后就去忙别的去了 2 、乙也打开了网页，拿到了 a 和 b ，然后把 b 修改成 b1 ，接着把 a 和 b1 一起提交上去 3 、甲回来了，把 a 修改成了 a1 ，然后把 a1 和 b 一起提交上去了 4 、最终就输 a1 和 b ，b1 的修改丢失了 正常前端都不会只传变更了的字段，而是偷懒一股脑都传上来 所以你后端其实根本判断不了 不过这其实也没啥大问题，因为通常来说一个表单的正确性就是取决于最后修改他的人而已 既然最后修改他的人觉得没问题，那其实也确实没啥大问题

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

真要说起来，这才是“正确”的（或者说是现代的）写法，前提是有乐观锁或者分布式锁 业务系统用数据库事务来做并发控制是个很不好的做法 参考 DDD 中的 repository 和 unit of work 模式 https://martinfowler.com/eaaCatalog/repository.html https://martinfowler.com/eaaCatalog/unitOfWork.html

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

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

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

@kanepan19 大佬

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

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