mysql锁详解

mysql锁详解

1.数据库锁机制

数据库提供两种锁：表锁和行锁
myisam存储引擎支持表锁
innodb存储引擎支持表锁和行锁

行锁分两种：共享锁和排它锁

共享锁：当数据被加上共享锁时，其他事务能对它进行查操作、加共享锁操作，但不能进行删改操作、加排它锁操作
排它锁：当数据对象被加上排它锁时，其他事务只能对数据进行查操作，且查的是被锁前的数据

行锁是在索引上加锁，所以只有通过索引条件检索数据，InnoDB才使用行级锁，否则，InnoDB将使用表锁！

意向锁：意向共享锁和意向排它锁，innodb为了允许行级锁与表级锁共存，而引入了意向锁(intention locks)。意向锁是指，未来的某个时刻，事务可能要加共享/排它锁了，先提前声明一个意向。事务要获得某些行的共享或排他锁，必须先获得表对应的意向共享锁或意向排它锁，意向锁仅仅表明意向，意向锁之间相互兼容，兼容互斥表如下：

意向共享锁(IS)：它预示着，事务有意向对表中的某些行加共享S锁
意向排它锁(IX)：它预示着，事务有意向对表中的某些行加排它X锁

间隙锁：当我们用范围条件而不是相等条件检索数据，并请求共享或排他锁时，InnoDB会给符合条件的已有数据记录的索引项加锁；假如emp表中只有101条记录，其id的值从1~101，下面的sql： select * from emp where id > 100 for update; 是范围条件查询，InnoDB不仅会对符合条件的id值为101的记录加锁，也会对id大于101（并不存在的值）的“间隙”加锁。很显然，在使用范围条件检索并锁定记录时，InnoDB这种加锁机制会阻塞符合条件范围内键值的并发插入，这往往会造成严重的锁等待。因此，在实际应用开发中，尤其是并发插入比较多的应用，我们要尽量优化业务逻辑，尽量使用相等条件来访问更新数据，避免使用范围条件。

2.web开发解决并发问题时常用的两种锁

1.乐观锁：在加锁的表中加一个字段代表版本号，通过版本号来控制并发，只有在更新的时候会判断是否加锁 ，这种模式是通过程序来实现的。
优点：不会阻止除程序外的数据库操作，不会出现死锁问题
响应速度快，不需要等待其他并发释放锁
缺点：可能会出现ABA问题。无法解决脏读问题。

乐观锁缺点
1.乐观锁在大量并发的情况下会返回大量的失败，需要重新操作直到成功为止

2.乐观锁存在失效的情况，属小概率事件，需要多个条件共同配合才会出现。如：
应用采用自己的策略管理主键ID。如，常见的取当前ID字段的最大值＋1作为新ID。
版本号字段 ver 默认值为 0 。
用户A读取了某个记录准备修改它。该记录正好是ID最大的记录，且之前没被修改过， ver 为默认值 0。
在用户A读取完成后，用户B恰好删除了该记录。之后，用户C又插入了一个新记录。
此时，阴差阳错的，新插入的记录的ID与用户A读取的记录的ID是一致的， 而版本号两者又都是默认值 0。
用户A在用户C操作完成后，修改完成记录并保存。由于ID、ver均可以匹配上， 因此用户A成功保存。但是，却把用户C插入的记录覆盖掉了。
3.会出现ABA问题，解决方法，引入版本号

2.悲观锁: 需要使用数据库的排它锁。当这条数据正在被操作时，其他并发无法进行任何操作。读的时候为后面的更新加 锁，后面的读操作都会等待，在读与更新的时候都会判断是否加锁，这种模式是通过数据库来实现的
缺点： 它的使用意味着性能的损耗，在高并发、锁定持续时间长的情况下，尤其严重。
会出现死锁问题