mysql的锁

锁是计算机在执行多线程或线程时用于并发访问·同一共享资源的同步机制，mysql中的锁是在服务器层或者存储引擎层实现的，保证了数据访问的一致性和有效性。
锁的基本原理可以概括为：
1.事务在修改当前数据之前，需要获得相应的锁
2.获得锁之后，事务便可以修改数据
3.该事务操作期间，这部分数据是锁定的，其他事务如果需要修改数据，需要等待当前事务提交或者回滚后释放锁。

1.查看锁

select * from performance_schema.data_locks; # 锁的概况
select * from information_schema.innodb_locks; # 版本锁的概况
show engine innodb status; #InnoDB整体状态，其中包括锁的情况
#在事务A中执行：
start transaction;
update account SET balance = 1000 where id = 1;
#在事务B中执行：
start transaction;
update account SET balance = 2000 where id = 1;

2.锁机制的重要性

并发用户访问同一数据，锁机制可以避免数据不一致问题的发生。

3.锁的分类

4.共享锁

又称为读锁，简称S锁，当事务A对数据加入读锁后，其他事务只能对该数据加读锁，不能做任何修改操作，也就是不能添加写锁。只有当事务A上的读锁被释放后，其他事务才能对其添加写锁。

应用场景：共享锁主要是为了支持并发的读取数据而出现的，读取数据时，不允许其他事务对当前数据进行修改操作，从而避免“不可重复读”的问题的出现。

select * from dept WHERE dept_id=50 LOCK IN SHARE MODE;

5.排它锁

又称写锁，独占锁，排他锁，简称x锁，当事务对数据写上加锁后。其他事务既不能对该数据添加读锁，也不能对该数据添加写锁，写锁与其他锁都是互斥的。只有当前数据写锁被释放了，其他事务才能对齐添加写锁或者是读锁。

特别需要注意到的是，MySQL中的InnoDB引擎默认update，delete，insert都会自动加上排他锁，select语句默认不会加任何类型的锁。
应用场景：写锁主要为了解决在修改数据时，不允许其他事务对当前数据进行修改和读取操作，从而可以有效避免脏读问题。

select * from dept WHERE dept_id=50 FOR UPDATE;

同时，必须关掉mysql的自动提交

6.锁的粒度分类

• 表级锁：开销小，加锁快，不会出现死锁，锁定力度大，发生锁冲突的概率高，并发度低。
• 行级锁：开销大，会出现死锁，锁定力度最小，发生锁冲突的概率最低，并发度高。
• 页面锁：开销和加锁时间介于表锁和行锁之间，会出现死锁，锁定力度介于表和行级锁之间，并发度一般。

mysql和memory存储引擎采用表级锁
InnoDB支持行级锁，表级锁，默认情况采用行级锁。

6.1 乐观锁

乐观锁是相对与悲观锁而言的，乐观锁假设数据一般情况下不会造成冲突，所以数据进行提交更新的时候，才会正式对数据的冲突与否进行检测。如果发现冲突了，则返回给用户错误的信息，让用户决定如何去做。

应用场景：适用于读多写少，如果出现大量冲突，写冲突的可能性就会增大，业务层需要不断重试，会大大降低系统的性能。
实现方式：一般使用数据版本（Version）记录机制实现，在数据库表中增加一个数字类型的“Version”字段来实现。

6.2 悲观锁

悲观锁，正如其名，具有强烈的独占和排他性，每次去拿数据时，都会认为别人会修改，对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改保持保守态度，因此，在整个处理过程中，将数据处于锁定状态。

适用场景：适用于并发量不大。写操作比较频繁，数据一致性比较高的场景。

实现方式：在mysql中使用悲观锁，必须关闭事务的自动提交，set autocommit=0。共享锁和排他锁都是悲观锁的不同实现，他俩都属于悲观锁的范畴。

6.3 死锁

什么时死锁？
当某组资源的两个或多个线程之间有循环关系时，将发生死锁。死锁是以一种可能发生在任何多线程系统中的状态，而不仅仅发生在数据库管理系统中。

那么，为了尽可能避免死锁的发生，用户应该遵循以下原则：

1. 在所有的事务中都按照同一顺序来访问各个表。尽可能利用存储过程来完成一个事务，以便能保证对各表的访问次序都是一致的。
2. 事务应该经量小且应该尽快提交。
3. 经量避免人工输入操作出现在事务中。
4. 经量避免同时执行诸如[INSERT]，[UPDATE]和[delete]等数据修改语句。