mysql的并发操作时而引起的数据的不一致性（数据冲突）：
丢失更新：两个用户（或以上）对同一个数据对象操作引起的数据丢失。
解决方案：1.悲观锁，假设丢失更新一定存在；sql后面加上for update；这是数据库的一种机制。
2.乐观锁，假设丢失更新不一定发生。update时候存在版本，更新时候按版本号进行更新。
一 乐观锁
乐观锁不是数据库自带的，需要我们自己去实现。乐观锁是指操作数据库时(更新操作)，想法很乐观，认为这次的操作不会导致冲突，在操作数据时，并不进行任何其他的特殊处理（也就是不加锁），而在进行更新后，再去判断是否有冲突了。
通常实现是这样的：在表中的数据进行操作时(更新)，先给数据表加一个版本(version)字段，每操作一次，将那条记录的版本号加1。也就是先查询出那条记录，获取出version字段,如果要对那条记录进行操作(更新),则先判断此刻version的值是否与刚刚查询出来时的version的值相等，如果相等，则说明这段期间，没有其他程序对其进行操作，则可以执行更新，将version字段的值加1；如果更新时发现此刻的version值与刚刚获取出来的version的值不相等，则说明这段期间已经有其他程序对其进行操作了，则不进行更新操作。
实现：
下单操作包括3步骤：
1.查询出商品信息 select (status,status,version) from t_goods where id=#{id} 2.根据商品信息生成订单 3.修改商品status为2 update t_goods set status=2,version=version+1 where id=#{id} and version=#{version};
除了自己手动实现乐观锁之外，现在网上许多框架已经封装好了乐观锁的实现，如hibernate，需要时，可能自行搜索"hiberate 乐观锁"试试看。
通过时间戳方式：
例如：
有这样一个表：
每次更新时update在条件后再附加一个时间为条件：
update user_info set password=‘somelog‘ where username=‘somelog‘ and time=‘2018-07-11‘;
二、悲观锁
与乐观锁相对应的就是悲观锁了。悲观锁就是在操作数据时，认为此操作会出现数据冲突，所以在进行每次操作时都要通过获取锁才能进行对相同数据的操作，这点跟java中的synchronized很相似，所以悲观锁需要耗费较多的时间。另外与乐观锁相对应的，悲观锁是由数据库自己实现了的，要用的时候，我们直接调用数据库的相关语句就可以了。
说到这里，由悲观锁涉及到的另外两个锁概念就出来了，它们就是共享锁与排它锁。共享锁和排它锁是悲观锁的不同的实现，它俩都属于悲观锁的范畴。
悲观锁分为两种：共享锁和排它锁
共享锁是其它事务可以读但是不能写
排他锁是只有自己得事务有权限对此数据进行读写
SQL写法
共享锁（S）：
SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE;
排他锁（X)：
SELECT * FROM table_name WHERE ... FOR UPDATE;
加锁必须先开启事务：begin;（开启事务）->加锁、操作->commit;（提交事务，归还锁）