网站建站之后需要维护吗,wordpress标签模板,seo服务商技术好的公司,惠城区龙丰街道1.死锁的概念死锁#xff1a;死锁一般是事务相互等待对方资源#xff0c;最后形成环路造成的。对于死锁#xff0c;数据库处理方法#xff1a;牺牲一个连接#xff0c;保证另外一个连接成功执行。发生死锁会返回ERROR#xff1a;1213 错误提示#xff0c;大部分的死锁In…1.死锁的概念死锁死锁一般是事务相互等待对方资源最后形成环路造成的。对于死锁数据库处理方法牺牲一个连接保证另外一个连接成功执行。发生死锁会返回ERROR1213 错误提示大部分的死锁InnoDB存储引擎本身可以侦测到不需要人为进行干预。注意InnoDB存储引擎并不会回滚大部分的错误异常像阻塞章节里面的例子但是死锁例外发现死锁后InnoDB存储引擎会马上回滚一个事务会返回1213错误。2.死锁的情形举例eg1步 骤事务1事务21begin;begin;2delete from info_area where id1;空3空update info_users set mobile18514656666 where mobile18514656620;4update info_users set mobile18514656666 where mobile18514656620;空5空delete from info_area where id1;分析死锁日志第一部分从日志里我们可以看到事务1当前正在执行update info_users set mobile18514656666 where mobile18514656620该条语句正在申请表info_users的索引IDX_MOBILE的X锁所以提示lock_mode X waiting第二部分然后日志的下半部分说明了事务2当前‘持有的锁’以及‘等待的锁’从日志的HOLDS THE LOCKS(S)块中我们可以看到事务2持有索引IDX_MOBILE的X锁并且是记录锁(Record Lock)。该锁是通过事务2在步骤2执行的update语句申请的。从日志的WAITING FOR THIS LOCK TO BE GRANTED块中我们可以看到事务2正在申请持有表info_area的索引GEN_CLUST_INDEX的X锁该锁是delete from info_area where id1;语句申请的。eg2步骤事务1事务21begin;begin;2update info_users set name’aaa’ where id1;空3空update info_users set namebbb where id2;4update info_users set namebbb where id2;空5update info_users set name’aaa’ where id1;eg3步骤事务1事务21begin;begin;2DELETE from users where uidbbb;执行成功3DELETE from users where uidbbb;等待空4ERROR 1213 (40001)insert INTO users VALUES(2,bbb); 成功分析死锁日志第一部分从日志里我们可以看到事务1当前正在执行DELETE from users where uidbbb;该条语句正在申请索引UID的X锁所以提示lock_mode X waiting第二部分然后日志的下半部分说明了事务2当前‘持有的锁’以及‘等待的锁’从日志的HOLDS THE LOCKS(S)块中我们可以看到事务2持有索引UID的X锁并且是记录锁(Record Lock)。该锁是通过事务2在步骤2执行的delete语句申请的。从日志的WAITING FOR THIS LOCK TO BE GRANTED块中我们可以看到事务2正在申请持有索引UID的S锁该锁是insert INTO users VALUES(2,bbb);语句申请的。insert语句在普通情况下是会申请X锁但是这里出现了S锁。这是因为uid字段是一个唯一索引所以insert语句会在插入前进行一次duplicate key的检查为了使这次检查成功需要申请S锁防止其他事务对uid字段进行修改。那么为什么该S锁会失败呢这是对同一个字段的锁的申请是需要排队的。S锁前面还有一个未申请成功的X锁所以S锁必须等待所以形成了循环等待死锁出现了。通过阅读死锁日志我们可以清楚地知道两个事务形成了怎样的循环等待再加以分析就可以逆向推断出循环等待的成因也就是死锁形成的原因。
