update 大家会允许这样写吗？

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

绝对不允许。

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

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

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

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

@kanepan19 大佬

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

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

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

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

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

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

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

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

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

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

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

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

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

首先，一般没有 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 覆盖。