mysql的锁

1.什么是锁?

　　锁是计算机协调多个进程或线程并发访问某一资源的机制

2.不同存储引擎有着不同的锁，举例子

　　MyISAM和MEMORY存储引擎:表级锁（table-level locking）；

　　BDB存储引擎采用的是页面锁（page-level locking），但也支持表级锁；

　　InnoDB存储引擎既支持行级锁（row-level locking），也支持表级锁，但默认情况下是采用行级锁。

3.InnoDB与Oracle的行锁有何不同？

　　innodb的行锁必须要有索引，才能加锁，oracle是直接对行数据加锁

4.什么是死锁

是指两个或两个以上的进程在执行过程中，因争夺资源而造成的一种互相等待的现象,若无外力作用,它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的过程称为死锁

5.如何处理死锁

对待死锁常见的两种策略：

　　1. 通过 innodblockwait_timeout 来设置超时时间，一直等待直到超时；

　　2.发起死锁检测，发现死锁之后，主动回滚死锁中的某一个事务，让其它事务继续执行。

6.InnoDB 默认是如何对待死锁的？

InnoDB 默认是使用设置死锁时间来让死锁超时的策略，默认 innodblockwait_timeout 设置的时长是 50s。

7.如何开启死锁检测？

设置 innodbdeadlockdetect 设置为 on 可以主动检测死锁，在 Innodb 中这个值默认就是 on 开启的状态。

8.什么是全局锁，它的应用场景

全局锁就是对整个数据库实例加锁，它的典型使用场景就是做全库逻辑备份。 这个命令可以使整个库处于只读状态。使用该命令之后，数据更新语句、数据定义语句、更新类事务的提交语句等操作都会被阻塞。

9.如何处理逻辑备份时，整个数据库不能插入的情况？

如果使用全局锁进行逻辑备份就会让整个库成为只读状态，幸好官方推出了一个逻辑备份工具 MySQLdump 来解决了这个问题，只需要在使用 MySQLdump 时，使用参数 -single-transaction 就会在导入数据之前启动一个事务来保证数据的一致性，并且这个过程是支持数据更新操作的。

10.什么是排它锁？

排他锁 exclusive lock（也叫 writer lock）又称写锁。

若某个事物对某一行加上了排他锁，只能这个事务对其进行读写，在此事务结束之前，其他事务不能对其进行加任何锁，其他进程可以读取,不能进行写操作，需等待其释放。

排它锁是悲观锁的一种实现，在上面悲观锁也介绍过。

若事务 1 对数据对象 A 加上 X 锁，事务 1 可以读 A 也可以修改 A，其他事务不能再对 A 加任何锁，直到事物 1 释放 A 上的锁。这保证了其他事务在事物 1 释放 A 上的锁之前不能再读取和修改 A。排它锁会阻塞所有的排它锁和共享锁。

 

11.innodb引擎有几种锁算法

　　1.Record Lock — 单个行记录上的锁；

　　2.Gap Lock — 间隙锁，锁定一个范围，不包括记录本身；

　　3.Next-Key Lock — 锁定一个范围，包括记录本身。

 

12. 优化锁方面你有什么建议？

　　1.尽量使用较低的隔离级别。

　　2. 精心设计索引， 并尽量使用索引访问数据， 使加锁更精确， 从而减少锁冲突的机会

　　3.选择合理的事务大小，小事务发生锁冲突的几率也更小。

　　4. 给记录集显示加锁时，最好一次性请求足够级别的锁。比如要修改数据的话，最好直接申请排他锁，而不是先申请共享锁，修改时再请求排他锁，这样容易产生死锁。

 

不少人在开发的时候，应该很少会注意到这些锁的问题，也很少会给程序加锁(除了库存这些对数量准确性要求极高的情况下)

一般也就听过常说的乐观锁和悲观锁，了解过基本的含义之后就没了~~~

即使我们不会这些锁知识，我们的程序在一般情况下还是可以跑得好好的。因为这些锁数据库隐式帮我们加了。

• 对于UPDATE，DELETE，INSERT语句，InnoDB会自动给涉及到的数据集加排它锁。
• MyISAM在执行SELECT之前，会自动给涉及到的所有表加读锁，在执行更新操作（UPDATE，DELETE，INSERT）前，会自动给涉及到的表加写锁，这个过程不需要用户干预。

只有某些特定的情况才需要我们手动加锁，那么我们学习锁的目的是什么呢？当然是为了装逼，人生不装逼，那还有什么意义。

一、锁简单介绍

从锁的粒度，可以分为两大类：

• 表锁：开销小，加锁快，不会出现死锁，锁定力度大，发生锁冲突的概率高，并发度低。
• 行锁：开销大，加锁慢，会出现死锁，锁定力度小，发生锁冲突的概率低，并发读高。

不同的存储引擎支持的锁力度是不一样的。

• InnoDB支持表锁和行锁。
• MyISAM只支持表锁。

InnoDB只有通过索引条件检索数据才使用行级锁，否则，InnoDB将使用表锁。也就是说，InnoDB的行锁是基于索引的。

表锁下又分为两种模式：

• 表读锁（Table Read Lock）
• 表写锁（Table Write Lock）

从下图可以清晰看到，在表读锁和表写锁的环境下：读读不阻塞，读写阻塞，写写阻塞！

读读不阻塞：当前用户在读数据，其他的用户也在读数据，不会加锁。

读写阻塞：当前用户在读数据，其他的用户不能修改当前用户读的数据，会加锁！

写写阻塞：当前用户在修改数据，其他的用户不能修改当前用户正在修改的数据，会加锁！

从上面已经看到了：读锁和写锁是互斥的，读写操作是串行。

• 如果某个进程想要获取读锁，同时另外一个进程想要获取写锁。在mysql里边，写锁是优先于读锁的！
• 写锁和读锁优先级的问题可以通过参数调节：max_write_lock_count和low-priority-updates

值得注意的是：

• MyISAM可以支持查询和插入操作的并发进行。可以通过系统变量concurrent_insert来指定哪种模式，在MyISAM中它默认是：如果MyISAM表中没有空洞（即表的中间没有被删除的行），MyISAM允许在一个进程读表的同时，另一个进程从表尾插入记录。
• 但是InnoDB存储引擎是不支持的！

二、MySQL的事务隔离级别

在这之前，先了解一下MySQL的事务隔离级别以及并发带来的问题。

事务的并发问题

1、脏读：事务A读取了事务B更新的数据，然后B回滚操作，那么A读取到的数据是脏数据

2、不可重复读：事务 A 多次读取同一数据，事务 B 在事务A多次读取的过程中，对数据作了更新并提交，导致事务A多次读取同一数据时，结果 不一致。

3、幻读：系统管理员A将数据库中所有学生的成绩从具体分数改为ABCDE等级，但是系统管理员B就在这个时候插入了一条具体分数的记录，当系统管理员A改结束后发现还有一条记录没有改过来，就好像发生了幻觉一样，这就叫幻读。

小结：不可重复读和幻读很容易混淆，不可重复读侧重于修改，幻读侧重于新增或删除。解决不可重复读的问题只需锁住满足条件的行，解决幻读需要锁表

MySQL事务隔离级别

MySQL的默认隔离级别是可重复读，可以通过下面的命令查看

select @@tx_isolation;

隔离级别越高，越能保证数据的完整性和一致性，但是对并发性能的影响也越大，鱼和熊掌不可兼得啊。对于多数应用程序，可以优先考虑把数据库系统的隔离级别设为Read Committed，它能够避免脏读取，而且具有较好的并发性能。尽管它会导致不可重复读、幻读这些并发问题，在可能出现这类问题的个别场合，可以由应用程序采用悲观锁或乐观锁来控制。

可以通过下面的命令设置事务隔离级别

set session transaction isolation level xxxx;

三、乐观锁和悲观锁

无论是Read committed还是Repeatable read隔离级别，都是为了解决读写冲突的问题。

单纯在Repeatable read隔离级别下我们来考虑一个问题：

此时，用户李四的操作就丢失掉了

丢失更新：一个事务的更新覆盖了其它事务的更新结果。

解决的方法：

• 使用Serializable隔离级别，事务是串行执行的！
• 乐观锁
• 悲观锁

乐观锁是一种思想，具体实现是，表中有一个版本字段，第一次读的时候，获取到这个字段。处理完业务逻辑开始更新的时候，需要再次查看该字段的值是否和第一次的一样。如果一样更新，反之拒绝。之所以叫乐观，因为这个模式没有从数据库加锁，等到更新的时候再判断是否可以更新。

悲观锁是数据库层面加锁，都会阻塞去等待锁。

1.悲观锁

所以，按照上面的例子。我们使用悲观锁的话其实很简单(手动加行锁就行了)：

select * from xxxx for update

在select 语句后边加了 for update相当于加了排它锁(写锁)，加了写锁以后，其他的事务就不能对它修改了！需要等待当前事务修改完之后才可以修改。也就是说，如果张三使用select … for update，李四就无法对该条记录修改了。

2.乐观锁

乐观锁不是数据库层面上的锁，不需要自己手动去加的锁。一般我们添加一个版本字段来实现：

具体过程是这样的：

张三select * from table —>会查询出记录出来，同时会有一个version字段

李四select * from table —>会查询出记录出来，同时会有一个version字段

李四对这条记录做修改

update A set age=30,version=version+1 where name=#{name} and version=#{version}

判断之前查询到的version与现在的数据的version进行比较，同时会更新version字段。

张三也对这条记录修改：update A set name=female,version=version+1 where name=#{name} and version=#{version}，但失败了！因为当前数据库中的版本跟查询出来的版本不一致！

四、间隙锁GPA

当我们用范围条件检索数据而不是相等条件检索数据，并请求共享或排他锁时，InnoDB会给符合范围条件的已有数据记录的索引项加锁；对于键值在条件范围内但并不存在的记录，叫做“间隙（GAP)”。InnoDB也会对这个“间隙”加锁，这种锁机制就是所谓的间隙锁。

值得注意的是：间隙锁只会在Repeatable read隔离级别下使用

例子：假如emp表中只有101条记录，其empid的值分别是1,2,…,100,101

Select * from emp where empid > 100 for update;

上面是一个范围查询，InnoDB不仅会对符合条件的empid值为101的记录加锁，也会对empid大于101（这些记录并不存在）的“间隙”加锁。

InnoDB使用间隙锁的目的：

• 为了防止幻读:在一个事务未提交前，其他并发事务不能插入满足其锁定条件的任何记录，也就是不允许出现幻读。

五、死锁

并发的问题就少不了死锁，在MySQL中同样会存在死锁的问题。

但一般来说MySQL通过回滚帮我们解决了不少死锁的问题了，但死锁是无法完全避免的，可以通过以下的经验参考，来尽可能少遇到死锁：

（1）以固定的顺序访问表和行。比如对两个job批量更新的情形，简单方法是对id列表先排序，后执行，这样就避免了交叉等待锁的情形；将两个事务的sql顺序调整为一致，也能避免死锁。

（2）大事务拆小。大事务更倾向于死锁，如果业务允许，将大事务拆小。

（3）在同一个事务中，尽可能做到一次锁定所需要的所有资源，减少死锁概率。

（4）降低隔离级别。如果业务允许，将隔离级别调低也是较好的选择，比如将隔离级别从RR调整为RC，可以避免掉很多因为gap锁造成的死锁。

（5）为表添加合理的索引。可以看到如果不走索引将会为表的每一行记录添加上锁，死锁的概率大大增大。

六、总结

上面说了一大堆关于MySQL数据库锁的东西，现在来简单总结一下。

表锁其实我们程序员是很少关心它的：

• 在MyISAM存储引擎中，当执行SQL语句的时候是自动加表锁的。
• 在InnoDB存储引擎中，如果没有使用索引，表锁也是自动加的。

现在我们大多数使用MySQL都是使用InnoDB，InnoDB支持行锁：

• 共享锁–读锁–S锁
• 排它锁–写锁–X锁

在默认的情况下，select是不加任何行锁的~事务可以通过以下语句显示给记录集加共享锁或排他锁。

// 共享锁（S）
SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE。
// 排他锁（X)
SELECT * FROM table_name WHERE ... FOR UPDATE。

InnoDB基于行锁还实现了MVCC多版本并发控制，MVCC在隔离级别下的Read committed和Repeatable read下工作。MVCC能够实现读写不阻塞！

InnoDB实现的Repeatable read隔离级别配合GAP间隙锁已经避免了幻读！

• 乐观锁其实是一种思想，正如其名：认为不会锁定的情况下去更新数据，如果发现不对劲，才不更新(回滚)。在数据库中往往添加一个version字段来实现。
• 悲观锁用的就是数据库的行锁，认为数据库会发生并发冲突，直接上来就把数据锁住，其他事务不能修改，直至提交了当前事务