数据库的各种锁（乐观锁，悲观锁等等各种锁)

我们才操作数据库的时候，可能会因为并发问题一起一系列的数据不一致的问题（数据冲突）
这时就需要锁了，

乐观锁

• 乐观锁不是系统自带的，得需要我们自己去实现
• 通常实现是这样的：在表中的数据进行操作时(更新)，先给数据表加一个版本(version)字段，每操作一次，将那条记录的版本号加1。也就是先查询出那条记录，获取出version字段,如果要对那条记录进行操作(更新),则先判断此刻version的值是否与刚刚查询出来时的version的值相等，如果相等，则说明这段期间，没有其他程序对其进行操作，则可以执行更新，将version字段的值加1；如果更新时发现此刻的version值与刚刚获取出来的version的值不相等，则说明这段期间已经有其他程序对其进行操作了，则不进行更新操作。
• 很多框架已经继承好了乐观锁（eg hibernate）
• 乐观锁的优势和劣势
  优势：如果数据库记录始终处于悲观锁加锁状态，可以想见，如果面对几百上千个并发，那么要不断的加锁减锁，而且用户等待的时间会非常的长， 乐观锁机制避免了长事务中的数据库加锁解锁开销，大大提升了大并发量下的系统整体性能表现 所以如果系统的并发非常大的话，悲观锁定会带来非常大的性能问题，所以建议就要选择乐观锁定的方法， 而如果并发量不大，完全可以使用悲观锁定的方法。乐观锁也适合于读比较多的场景。
  劣势： 但是乐观锁也存在着问题，只能在提交数据时才发现业务事务将要失败，如果系统的冲突非常的多，而且一旦冲突就要因为重新计算提交而造成较大的代价的话，乐观锁也会带来很大的问题，在某些情况下，发现失败太迟的代价会非常的大。而且乐观锁也无法解决脏读的问题

悲观锁

• 与乐观锁相对应的就是悲观锁了。悲观锁就是在操作数据时，认为此操作会出现数据冲突，所以在进行每次操作时都要通过获取锁才能进行对相同数据的操作，这点跟java中的synchronized很相似，所以悲观锁需要耗费较多的时间。另外与乐观锁相对应的，悲观锁是由数据库自己实现了的，要用的时候，我们直接调用数据库的相关语句就可以了。
  说到这里，由悲观锁涉及到的另外两个锁概念就出来了，它们就是共享锁与排它锁。共享锁和排它锁是悲观锁的不同的实现，它俩都属于悲观锁的范畴。
• 劣势：开销较大，而且加锁时间较长，对于并发的访问性支持不好。
  优势 ： 能避免冲突的发生，

1、共享锁

2、排它锁

行锁

行锁，由字面意思理解，就是给某一行加上锁，也就是一条记录加上锁。
比如之前演示的共享锁语句
SELECT * from city where id = "1" lock in share mode;
由于对于city表中,id字段为主键，就也相当于索引。执行加锁时，会将id这个索引为1的记录加上锁，那么这个锁就是行锁

表锁

表锁，和行锁相对应，给这个表加上锁。
MyISAM引擎里有的，暂时研究了

死锁

指两个事务或者多个事务在同一资源上相互占有，并请求对方所占资源，从而造成恶性循环的现象

• 出现死锁的原因