MySQL——死锁
Posted php开发全程
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了MySQL——死锁相关的知识，希望对你有一定的参考价值。
之前分享了关于mysql锁的内容，今天介绍一下MySQL数据库关于死锁的内容。
数据库是一个多用户使用的共享资源。当多个用户并发地存取数据 时，在数据库中就会发生多个事务同时存取同一数据的情况。若对并发操作不加限制就可能会读取和存储不正确的数据，破坏数据库的一致性。加锁是实现数据库并 发控制的一个非常重要的技术。在实际应用中经常会遇到的与锁相关的异常情况，当两个或多个事务需要获取一组有冲突的锁，就无法将事务继续下去，这就是死锁，死锁严重影响了程序的正常执行。
在常见的存储引擎中( MyISAM 和 InnoDB )，只有 InnoDB 引擎的表会发生死锁，这是因为 MyISAM 总是一次获得所需的全部锁，要么全部满足，要么等待，因此不会出现死锁。但在 InnoDB 中，除单个SQL组成的事务外，锁是逐步获得的，这就决定了在 InnoDB 中发生死锁是可能的。
简单的 InnoDB 存储引擎死锁的例子
| session_1 | session_2 |
mysql> set autocommit = 0; Query OK, 0 rows affected (0.00 sec) mysql> select * from tab_1 where where id=1 for update; ... 获取表tab_1排它锁 |
mysql> set autocommit = 0; Query OK, 0 rows affected (0.00 sec) mysql> select * from tab_2 where id=1 for update; ... 获取表tab_2排它锁 |
select * from table_2 where id =1 for update; 因session_2已取得排他锁，等待 |
( InnoDB引擎默认执行完SQL自动提交，所以上面两个会话，通过设置 autocommit=0 将自动提交关闭) |
mysql> select * from table_1 where where id=1 for update; 死锁 |
在上面的例子中，两个事务都需要获得对方持有的排他锁才能继续完成事务，这种循环锁等待就是典型的死锁。
虽然进程在运行过程中，可能发生死锁，但死锁的发生也必须具备一定的条件，死锁的发生必须具备以下四个必要条件。
1）互斥条件：指进程对所分配到的资源进行排它性使用，即在一段时间内某资源只由一个进程占用。如果此时还有其它进程请求资源，则请求者只能等待，直至占有资源的进程用毕释放。
2）请求和保持条件：指进程已经保持至少一个资源，但又提出了新的资源请求，而该资源已被其它进程占有，此时请求进程阻塞，但又对自己已获得的其它资源保持不放。
3）不可剥夺条件：指进程已获得的资源，在未使用完之前，不能被剥夺，只能在使用完时由自己释放。
4）循环等待条件：指在发生死锁时，必然存在一个进程——资源的环形链，例如：进程A1等待进程A2占用的一个资源，A2在等待进程A3占用的资源······进程An在等待A1占用的资源。
一般情况只发生锁超时，就是一个进程需要访问数据库表或者字段的时候，另外一个程序正在执行带锁的访问（比如修改数据），那么这个进程就会等待，当等了很久锁还没有解除的话就会锁超时，报告一个系统错误，拒绝执行相应的SQL操作。
发生死锁的情况比较少，比如一个进程需要访问两个资源（数据库表或者字段），当获取一个资源的时候进程就对它执行锁定，然后等待下一个资源空闲，这时候如果另外一个进程也需要两个资源，而已经获得并锁定了第二个资源，那么就会死锁，因为当前进程锁定第一个资源等待第二个资源，而另外一个进程锁定了第二个资源等待第一个资源，两个进程都永远得不到满足。
理解了死锁的原因，尤其是产生死锁的四个必要条件，就可以最大可能地避免、预防和解除死锁。所以，在系统设计、进程调度等方面注意如何不让这四个必要条件成立，如何确定资源的合理分配算法，避免进程永久占据系统资源。此外，也要防止进程在处于等待状态的情况下占用资源,在系统运行过程中，对进程发出的每一个系统能够满足的资源申请进行动态检查，并根据检查结果决定是否分配资源，若分配后系统可能发生死锁，则不予分配，否则予以分配 。因此，对资源的分配要给予合理的规划。
虽然不能完全避免死锁，但可以使死锁的数量减至最少。将死锁减至最少可以增加事务的吞吐量并减少系统开销，因为只有很少的事务回滚，而回滚会取消事务执行的所有工作。由于死锁时回滚而由应用程序重新提交。
下列方法有助于最大限度地降低死锁：
（1）按同一顺序访问对象。
（2）避免事务中的用户交互。
（3）保持事务简短并在一个批处理中。
（4）使用低隔离级别。
按同一顺序访问对象：
如果所有并发事务按同一顺序访问对象，则发生死锁的可能性会降低。例如，如果两个并发事务获得 tab_1 表上的锁，然后获得 tab_2 表上的锁，则在其中一个事务完成之前，另一个事务被阻塞在 tab_1 表上。第一个事务提交或回滚后，第二个事务继续进行。不发生死锁。将存储过程用于所有的数据修改可以标准化访问对象的顺序。
避免事务中的用户交互：
避免编写包含用户交互的事务，因为运行没有用户交互的批处理的速度要远远快于用户手动响应查询的速度，例如答复应用程序请求参数的提示。如果事务正在等待用户输入，而用户去吃午餐了或者甚至回家过周末了，则用户将此事务挂起使之不能完成。这样将降低系统的吞吐量，因为事务持有的任何锁只有在事务提交或回滚时才会释放。即使不出现死锁的情况，访问同一资源的其它事务也会被阻塞，等待该事务完成。
保持事务简短并在一个批处理中：
在同一数据库中并发执行多个需要长时间运行的事务时通常发生死锁。事务运行时间越长，其持有排它锁或更新锁的时间也就越长，从而堵塞了其它活动并可能导致死锁。保持事务在一个批处理中，可以最小化事务的网络通信往返量，减少完成事务可能的延迟并释放锁。
使用低隔离级别：
确定事务是否能在更低的隔离级别上运行。执行提交读允许事务读取另一个事务已读取（未修改）的数据，而不必等待第一个事务完成。如果业务允许的话，使用较低的隔离级别（例如提交读）而不使用较高的隔离级别（例如可串行读）可以缩短持有共享锁的时间，从而降低了锁定争夺。
发生死锁后，InnoDB一般都能自动检测到，并使一个事务释放锁并回退，另一个事务获得锁，继续完成事务。但在涉及外部锁，或涉及表锁的情况下，InnoDB并不能完全自动检测到死锁，这需要通过设置锁等待超时参数 innodb_lock_wait_timeout 来解决。用show variables like 'innodb_lock_wait_timeout' 语句查看参数的值，用 SET var_name = value 语句可以改变参数的值。
需要说明的是，这个参数并不是只用来解决死锁问题，在并发访问比较高的情况下，如果大量事务因无法立即获得所需的锁而挂起，会占用大量计算机资源，造成严重性能问题，甚至拖跨数据库。我们通过设置合适的锁等待超时阈值，可以避免这种情况发生。
通常来说，死锁都是应用设计的问题，通过调整业务流程、数据库对象设计、事务大小，以及访问数据库的SQL语句，绝大部分死锁都可以避免。
如果出现死锁，可以用 SHOW ENGINE INNODB STATUS 命令来查看最后一个死锁产生的信息。返回结果中包括死锁相关事务的详细信息，如引发死锁的SQL语句，事务已经获得的锁，正在等待什么锁，以及被回滚的事务等。据此可以分析死锁产生的原因和改进措施。由于返回的数据很多，这里就不介绍。以上就是关于死锁的介绍，如有错误欢迎指正~
不懂的留言，每天一篇分享，玩转我们共同的爱好！
你也来投搞！
以上是关于MySQL——死锁的主要内容，如果未能解决你的问题，请参考以下文章