请教大家： 如何解决数据库并发操作导致的数据不一致问题？(mysql)

乐观锁可以解决吧

没有看出数据不一致。。
如果是防止同时更改，可以对该条数据加锁啊

这个不是锁能够搞定的, 而是程序逻辑的问题.
A 改动的是 年龄
B 改动的是性别
两个操作本身不冲突的, 现在冲突是因为 代码修改的是全部...

解决办法
只保存 要修改的那一个字段, 不要都修改.

你可以加个时间戳， A 保存时更新时间戳， B 保存时获取时间戳，对比是否更新过，如果更新过，提示用户。
甚至可以用存储过程，让数据库自动保证数据一致。

3L+1

这确实是程序的问题

你知道锁吗？

SELECT FOR UPDATE

保存前检查数据是否为修改前的数据

LZ 的问题不在于加不加锁，关键是都用了全量更新
所以为了避免这种情况都是只更新修改的字段，非空字段不更新
不要拿查询出来的对象去更新，而是 new 一个新的对象仅把之前查询出来的对象的主键 set 进去

事务隔离级别设置为， serializable
连读都加锁，你说好不好啊

锁解决不了。

前台只提交更改的就行。

如果可以，考虑下 websock 实时更新并提醒。

@shoaly
感觉问题被你带偏了。。。
其实题主都没有说真实场景，万一张三的信息确实如 B 的更改呢？

所以题主－－－表达清楚需求啊！

楼主的这个场景涉及前台，无法直接锁行，同意 @hp3325 的观点，使用乐观锁，增加时间戳，保存时比较，冲突了提示用户手工修正。

其他的并发能使用事务+悲观锁就直接锁行，简单方便快捷。

性别如今也不是不能改的...要政治正确啊。参考 FaceBook

用 etag
A ， B 在读取信息时，保存信息的 etag ，
然后在发送更新请求时带上 etag ，执行数据库更新操作前检查 etag 是否变化，如果 etag 一致，保存更新，否则更新失败

这还叫并发 。。
难道修改不应该保存修改记录吗？
redis 好像有原子操作更新数据前检测数据有没有变化过

难道不是 1L 说的乐观锁就解决了么 ...

SELECT FOR UPDATE +1

说具体一下：
看需求，并发修改同一行数据，
如果期望 B 操作无效，用乐观锁
如果期望按时间顺序执行（ B 也会执行），用 select for update

你真的希望 A ， B 的操作都生效吗？感觉会是一场灾难

两种场景。
1. 单字段更新。写入数据库的时候只写入脏数据，这样就不会撤销之前的更改。
2. 完整对象更新。如 13 楼所说，确实有按照 B 的修改完整写入的需求。

如果是 innodb 存储引擎的表的话，在这种并发写的情况下：
两种决定因素：
1 ）事物隔离级别是哪种
2 ） update 更新数据时候 where 查询条件列是否有索引，有的话是主键 /唯一 /非唯一索引

select for update 可以吧，一个人在操作一条数据的时候，另外一个连读这条数据的权限都不给

3L 真是目光如炬