MySQL死锁产生原因及解决方法.docxVIP

一.Mysql锁类型和加锁分析 1、锁类型介绍： MySQL有三种锁的级别：页级、表级、行级。 ?表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最 高■并发度最低。 ?行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最 低■并发度也最高。 ?页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表 锁和行锁之间，并发度一般 算法： next KeyLocks锁，同时锁住记录（数据），并且锁住记录前面的Gap Gap锁，不锁记录，仅仅记录前面的Gap Recordlock锁（锁数拯，不锁Gap） 所以其实 Next-KeyLocks=Gap 锁 + Recordlock 锁 二、死锁产生原因和示例 1、产生原因： 所谓死锁：是指两个或两个以上的进程在执行过程中，因争夺资源而造成的 一种互相等待的现象，若无外力作用，它们都将无法推进下去?此时称系统处于死 锁状态或系统产生了死锁，这些永远在互相等待的进程称为死锁进程。表级锁 不会产生死锁?所以解决死锁主要还是针对于最常用的InnoDBo ?死锁的关键在于：两个（或以上）的Session加锁的顺序不一致。 ?那么对应的解决死锁问题的关键就是：让不同的session加锁有次序 2、产生示例： 案例一 需求：将投资的钱拆成儿份随机分配给借款人。 起初业务程序思路是这样的： 投资人投资后，将金额随机分为儿份，然后随机从借款人表里面选儿个，然后 通过一条条select for update去更新借款人表里面的余额等。 例如两个用户同时投资，A用户金额随机分为2份，分给借款人1, 2 B用户金额随机分为2份，分给借款人2, 1 山于加锁的顺序不一样，死锁当然很快就出现了。 对于这个问题的改进很简单，直接把所有分配到的借款人直接一次锁住就行了。 Select * from xxx where id in （xx,xx,xx） for up date 在in里面的列表值mysql是会自动从小到大排序，加锁也是一条条从小到大加 的锁 例如（以下会话id为主键）： Session 1: mysql select * from t3 where id in （9） for update; I id I course I name I dime I 8IWA If 12016-03-02 11:36:301 I 91JX If 12016-03-01 11:36:301 rows in set (0.04 sec) Session2: select * from t3 where id in (10,5) for update; 锁等待中 我实这个时候id=10这条记录没有被锁住的，但id=5的记录已经被锁住了, 锁的等待在id=8的这里，不信请看。 Sessions： mysql select * from t3 where id=5 for up date; 锁等待中 Session4: mysql select * from t3 where id=10 for up date; I id I course 1 name I dime I lOIJB Ig 12016-03-10 11:45:05 I row in set （0.00 sec） 在其它session中id=5是加不了锁的，但是id=10是可以加上锁的。 案例二 在开发中，经常会做这类的判断需求：根据字段值査询（有索引），如果 不存在，则插入；否则更新。 以id为主键为例，U前还没有id=22的行 Session 1: select * from t3 where id=22 for up date; Empty set （0.00 sec） session2: select * from t3 where id=23 for up date; Empty set （0.00 sec） Session I: insert into t3 values（22?ac7a\now（））; 锁等待中 Session2: insert into t3 values（23?bc7b\now（））; ERROR 1213 （40001）: Deadlock found when trying to get lock; try restarting transact ion 当对存在的行进行锁的时候（主键）.inysql就只有行锁。 当对未存在的行进行锁的时候（即使条件为主键），mysql是会锁住一段范H （有gap锁） 锁住的范W为^ （无穷小或小于表中锁住id的最大值，无穷大或大于表中锁住id的最小值） 如：如果表中U询有已有的id为（H , 12） 那么就锁住02,无穷大） 如果表中UhuB有的