[导读]在处理锁的问题上，经常听到：共享锁、排它锁、悲观锁、乐观锁、行级锁、表级锁。共享锁： 就是在读取数据的时候，给数据添加一个共享锁。共享和共享直接是不冲突的，但是和排他锁是冲突的。排他锁： 更新数据的时候... 在处理锁的问题上，经常听到：共享锁、排它锁、悲观锁、乐观锁、行级锁、表级锁。

共享锁： 就是在读取数据的时候，给数据添加一个共享锁。共享和共享直接是不冲突的，但是和排他锁是冲突的。
排他锁： 更新数据的时候，安装排他锁，禁止其他一切行为。


场 景：老公去在 ATM 上取钱，老婆在柜台存钱，假设这个账户中有 1000 元。老公首先执行查询操作，查询到账户余额为 1000 此时程序 将 1000 拿到内存中，老公取了200 元，程序就执行了更新操作将账户余额改为 800，但是当老公的程序没有 commit 的时候，老婆查询账户，此时账户余额还是 1000 元，老婆存入 200 元，程序执行了更新操作将账户余额改为 1200，然后老公将更新语句提交，接着老婆也将更新语句提交。最后导致的结果就是该账户的余额为 1200，这就是更新丢失的问题。引发更新丢失的根源就是查询上，因为双方都是根据从数据库查询到的数据再对数据库中的数据进行更新的。


解决更新丢失有三个方案：
(1) 将事务隔离级别设置为最高，采用死锁策略。
(2) 采用悲观锁，悲观锁不是数据库中真正的锁，是人们看待事务的态度。
(3) 采用乐观锁，乐观锁也不是数据库中真正的锁。


如 果我们采用的是第一个方案时，老公进行查询操作，数据库为表增加了共享锁，老婆进行查询操作时数据库也增加了一个共享锁。但是当老公进行更新数据库操作 时，由于老婆拿着共享锁，导致老公不能增加排它锁，老婆进行更新操作时，因为老公拿着共享锁，导致老婆也拿不到排它锁，这就发生了死锁现象，你等我，我等你。在 mysql 中，处理死锁的方案是释放掉一方的锁。这样就保证了一方更新成功，但是这种性能极低，因为数据库频繁在解决死锁问题。


悲观锁（更新多，查询少时用）
如果我们采用的是第二个方案时，即采用悲观锁。就是我们在操作数据库时采用悲观的态度，认为别人会在此时并发访问数据库。
我们在查询语句中 select * from account where name='aaa' for update; 等于加了排它锁。
当老公查询余额的时候，select money from account where name='aaa' for update; 增加了排它锁，
老婆查询账户余额的时候， select money from account where name='aaa' for update; 也要求对数据库加排它锁，
因为老公已经拿到了排它锁，导致老婆不能加锁，所以老婆只有等待老公执行完毕，释放掉锁以后才能继续操作。


乐观锁（更新少，查询多时用）
如 果我们采用的是第三个方案时，即采用乐观锁，就是我们在操作数据库的时候会认为没有其它用户并发访问，但是乐观锁也不是完全乐观的，乐观锁是采用版本号的 方式进行控制的。在数据库表中有一列版本号。从数据库中查询的时候，将版本号也查询过来，在进行更新操作的时候，将版本号加1，查询条件的版本号还是查询过来的版本号。
比如：
老公执行查询操作
select money,version from account where name='aaa'; 
假设此时查询到的版本号为 0，
老公在进行更新操作
update account set money=money+100,version=version+1 where name='aaa' and version=0; 
未提交时老婆来查询，查询到的版本号依然是 0，
老婆也执行更新操作
update account set money=money+100,version=version+1 where name='aaa' and version=0;
现在老公提交了事务，老婆再提交事务的时候发现版本号为 0 的记录没有了，所以就避免了数据丢失的问题。不过这种情况也导致了多个用户更新操作时，只有一个用户的更新被执行。


行级别的锁：
select * from employee where employeeID=9857 for update;  where 后边是索引列 不是索引列那么就为表级别的锁