在高并发的场景下，经常会遇到这种情况：
A请求过来，查询出来一条数据，进行update操作，与此同时B请求也在这个时候过来，对这条数据进行查询，并进行操作。此时就会出现B在A之后进行查询操作，但是实际B的数据却被A覆盖。

表名A，字段名为 number，如下的SQL语句:

甲操作 语句1：select num from store where id='1';

假设此时甲获取到 num= 99

乙操作 语句2：select num from store where id='1';

因为甲方还没有update操作，乙获也取到 num= 99
这时候A进行update操作

update store set num =${num} +1 where id='1';

这时候写入数据库的num即为100
此时B请求也发起了更新操作：

update store set num =${num} +1 where id='1';

这时候我们的预期本应该是101的，但是实际上B又在数据库写入了100

解决方案：

（1）引入一个版本号的概念，在表A中增加一个version字段

甲操作 语句1：select num,version from store where id='1';

假设此时甲获取到 num= 99 version =1

乙操作 语句2：select num,version from store where id='1';

因为甲方还没有update操作，乙获也取到 num= 99 version=1
这时候A进行update操作

update store set num =${num} +1 where id='1' and version = ${version};

这时候写入数据库的num即为100, version =2
此时B请求也发起了更新操作：

update store set num =${num} +1 where id='1' and version = ${version} ;

这时候发现条件version = 1不成立，因为上一步操作version已经为2了，所以update无法更新。

（2）解决方式：update A set number=number+1 where id=1; 语句直接处理

表名A，字段名为 number，如下的SQL语句:

语句1：update A set number=number+1 where id=1;
语句2：update A set number=number+2 where id=1;

假设这两条SQL语句同时被mysql执行，id=1的记录中number字段的原始值为99，那么是否有可能出现这种情况：
语句1和2因为同时执行，他们得到的number的值都是99，都是在10的基础上分别加1和2，导致最终number被更新为100或101，而不是102

这个其实就是 关系型数据库本身就需要解决的问题。首先，他们同时被MySQL执行，你的意思其实就是他们是并发执行的，而并发执行的事务在关系型数据库中是有专门的理论支持的- ACID，事务并行等理论，所有关系型数据库实现，包括Oracle， MySQL都需要遵循这个原理。
简单一点理解就是锁的原理。这个时候第一个update会持有id=1这行记录的 排它锁，第二个update需要持有这个记录的排它锁的才能对他进行修改，正常的话， 第二个update会阻塞，直到第一个update提交成功，他才会获得这个锁，从而对数据进行修改。
也就是说，按照关系型数据库的理论，这两个update都成功的话，id=1的number一定会被修改成22。如果不是22， 那就是数据库实现的一个严重的bug。