mysql死锁

知识储备：

1、官方文档上说mysql是支持非锁定读的；这个功能是这样实现的，如果事务a 要对行的数据进行更新的话，那么事务a要得到行的x锁，并把这一行

之前的样子记录在undo log里面，这样一来如果a 事务rollback 了就可以通过undo log 来恢复到之前的样子；说白了非锁定的一致性读就是读的

行的undo log 中的内容，所以这货根本就不用上锁。

2、在mysql中事务与锁的关系：

1、事务开始之后申请锁。

2、得到锁之后才进行相关的操作，事务提交或回滚之后才会去释放申请到的锁。

3、如果想要select 语句也加上s锁可以在select 后面加上lock in share mode 子句。

4、mysql支持意向锁、意向锁是在表级别上的；
　　5、innodb 对锁的分配方式：

1、innodb 的锁是需要用到的时候才会去分配，并是一次性要把事务要用到的锁分配完成后才去执行事务。

2、对锁的申请请求是放在一个队列当中的，请申请的先得到。
　　　 例子：一个lock in share mode 引起的死锁问题：
1、准备环境：

create database tempdb;
use tempdb;
create table t(x int);
insert into t(x) values(1);

2、事务一执行如下语句：

复制代码

mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from t where x=1 lock in share mode;

+------+
| x    |
+------+
|    1 |
+------+
1 row in set (0.00 sec)

复制代码
　　3、事务二执行如下语句：

mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)

mysql> delete from t where x=1;

4、接着事务一又执行如下语句：

mysql> delete from t where x=1;

5、最后mysql 监控到死锁

ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

原因分析：

1、事务一先是得到了x=1 这一行上的s 锁；

　　2、事务二要去申请x=1    这一行上的x锁，由于事务一已经得到了s锁，所以它要等待事务一释放s锁。

　　3、事务一又想去申请x=1  这一行上的x锁，由于事务二的申请在事务一的前面发起，所以它要等待事务二完成后才能得到。

由以上分析可知，事务一，事务二产生了相互等待；进而死锁产生。
用户A查询一条纪录，然后修改该条纪录；这时用户B修改该条纪录，这时用户A的事务里锁的性质由查询的共享锁企图上升到独占锁，而用户B里的独占锁由于A 有共享锁存在所以必须等A释放掉共享锁，而A由于B的独占锁而无法上升的独占锁也就不可能释放共享锁，于是出现了死锁。这种死锁比较隐蔽，但在稍大点的项 目中经常发生。如在某项目中，页面上的按钮点击后，没有使按钮立刻失效，使得用户会多次快速点击同一按钮，这样同一段代码对数据库同一条记录进行多次操 作，很容易就出现这种死锁的情况。

解决方法：

1、对于按钮等控件，点击后使其立刻失效，不让用户重复点击，避免对同时对同一条记录操作。
2、使用乐观锁进行控制。乐观锁大多是基于数据版本（Version）记录机制实现。即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是 通过为数据库表增加一个“version”字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数 据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。乐观锁机制避免了长事务中的数据 库加锁开销（用户A和用户B操作过程中，都没有对数据库数据加锁），大大提升了大并发量下的系统整体性能表现。Hibernate 在其数据访问引擎中内置了乐观锁实现。需要注意的是，由于乐观锁机制是在我们的系统中实现，来自外部系统的用户更新操作不受我们系统的控制，因此可能会造 成脏数据被更新到数据库中。
3、使用悲观锁进行控制。悲观锁大多数情况下依靠数据库的锁机制实现，如Oracle的Select … for update语句，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。如一个金融系统， 当某个操作员读取用户的数据，并在读出的用户数据的基础上进行修改时（如更改用户账户余额），如果采用悲观锁机制，也就意味着整个操作过程中（从操作员读 出数据、开始修改直至提交修改结果的全过程，甚至还包括操作员中途去煮咖啡的时间），数据库记录始终处于加锁状态，可以想见，如果面对成百上千个并发，这 样的情况将导致灾难性的后果。所以，采用悲观锁进行控制时一定要考虑清楚。