锐客网

  1. 首页 > 生活百科 > it技术 > >

mysql死锁怎么解决 mysql死锁解决方法

死锁IT技术

mysql 发生死锁问题请求帮助这是mysql死锁怎么解决我见的一个文档mysql死锁怎么解决，虽然我看不懂mysql死锁怎么解决，你看看有没有帮助
MySQL死锁问题的相关知识是本文我们主要要介绍的内容，接下来我们就来一一介绍这部分内容，希望能够对您有所帮助 。
1、MySQL常用存储引擎的锁机制
MyISAM和MEMORY采用表级锁(table-level locking)
BDB采用页面锁(page-level locking)或表级锁，默认为页面锁
InnoDB支持行级锁(row-level locking)和表级锁 ， 默认为行级锁
2、各种锁特点
【mysql死锁怎么解决 mysql死锁解决方法】表级锁：开销小，加锁快;不会出现死锁;锁定粒度大，发生锁冲突的概率最高，并发度最低
行级锁：开销大，加锁慢;会出现死锁;锁定粒度最?。⑸逋坏母怕首畹停?并发度也最高
页面锁：开销和加锁时间界于表锁和行锁之间;会出现死锁;锁定粒度界于表锁和行锁之间，并发度一般
3、各种锁的适用场景
表级锁更适合于以查询为主，只有少量按索引条件更新数据的应用，如Web应用
行级锁则更适合于有大量按索引条件并发更新数据，同时又有并发查询的应用，如一些在线事务处理系统
4、死锁
是指两个或两个以上的进程在执行过程中，因争夺资源而造成的一种互相等待的现象 ， 若无外力作用，它们都将无法推进下去 。
表级锁不会产生死锁 。所以解决死锁主要还是针对于最常用的InnoDB 。
5、死锁举例分析
在MySQL中，行级锁并不是直接锁记录，而是锁索引 。索引分为主键索引和非主键索引两种 ， 如果一条sql语句操作了主键索引，MySQL就会锁定这条主键索引;如果一条语句操作了非主键索引，MySQL会先锁定该非主键索引，再锁定相关的主键索引 。
在UPDATE、DELETE操作时，MySQL不仅锁定WHERE条件扫描过的所有索引记录，而且会锁定相邻的键值 ， 即所谓的next-key locking 。
例如，一个表db 。tab_test，结构如下：
id：主键;
state：状态;
time：时间;
索引：idx_1(state，time)
出现死锁日志如下：
?***(1) TRANSACTION:
?TRANSACTION 0 677833455, ACTIVE 0 sec, process no 11393, OSthread id 278546 starting index read
?mysql tables in use 1, locked 1
?LOCK WAIT 3 lock struct(s), heap size 320
?MySQL thread id 83, query id 162348740 dcnet03 dcnet Searching rows for update
?update tab_test set state=1064,time=now() where state=1061 and timedate_sub(now(), INTERVAL 30 minute) (任务1的sql语句)
?***(1) WAITING FOR THIS LOCK TO BE GRANTED: (任务1等待的索引记录)
?RECORD LOCKS space id 0 page no 849384 n bits 208 index `PRIMARY` of table `db/tab_test` trx id 0 677833455 _mode X locks rec but not gap waiting
?Record lock, heap no 92 PHYSICAL RECORD: n_fields 11; compact format; info bits 0
?0: len 8; hex 800000000097629c; asc b ;; 1: len 6; hex 00002866eaee; asc (f ;; 2: len 7; hex 00000d40040110; asc @ ;; 3: len 8; hex 80000000000050b2; asc P ;; 4: len 8; hex 800000000000502a; asc P*;; 5: len 8; hex 8000000000005426; asc T;; 6: len 8; hex 800012412c66d29c; asc A,f ;; 7: len 23; hex 75706c6f6164666972652e636f6d2f6 8616e642e706870; asc xxx.com/;; 8: len 8; hex 800000000000042b; asc;; 9: len 4; hex 474bfa2b; asc GK;; 10: len 8; hex 8000000000004e24; asc N$;;
?*** (2) TRANSACTION:
?TRANSACTION 0 677833454, ACTIVE 0 sec, process no 11397, OS thread id 344086 updating or deleting, thread declared inside InnoDB 499
?mysql tables in use 1, locked 1
?3 lock struct(s), heap size 320, undo log entries 1
?MySQL thread id 84, query id 162348739 dcnet03 dcnet Updating update tab_test set state=1067,time=now () where id in (9921180) (任务2的sql语句)
?*** (2) HOLDS THE LOCK(S): (任务2已获得的锁)
?RECORD LOCKS space id 0 page no 849384 n bits 208 index `PRIMARY` of table `db/tab_test` trx id 0 677833454 lock_mode X locks rec but not gap
?Record lock, heap no 92 PHYSICAL RECORD: n_fields 11; compact format; info bits 0
?0: len 8; hex 800000000097629c; asc b ;; 1: len 6; hex 00002866eaee; asc (f ;; 2: len 7; hex 00000d40040110; asc @ ;; 3: len 8; hex 80000000000050b2; asc P ;; 4: len 8; hex 800000000000502a; asc P*;; 5: len 8; hex 8000000000005426; asc T;; 6: len 8; hex 800012412c66d29c; asc A,f ;; 7: len 23; hex 75706c6f6164666972652e636f6d2f6 8616e642e706870; asc uploadfire.com/hand.php;; 8: len 8; hex 800000000000042b; asc;; 9: len 4; hex 474bfa2b; asc GK;; 10: len 8; hex 8000000000004e24; asc N$;;
?*** (2) WAITING FOR THIS LOCK TO BE GRANTED: (任务2等待的锁)
?RECORD LOCKS space id 0 page no 843102 n bits 600 index `idx_1` of table `db/tab_test` trx id 0 677833454 lock_mode X locks rec but not gap waiting
?Record lock, heap no 395 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
?0: len 8; hex 8000000000000425; asc %;; 1: len 8; hex 800012412c66d29c; asc A,f ;; 2: len 8; hex 800000000097629c; asc b ;;
?*** WE ROLL BACK TRANSACTION (1)
?(回滚了任务1，以解除死锁)
原因分析：
当“update tab_test set state=1064,time=now() where state=1061 and timedate_sub(now(), INTERVAL 30 minute)”执行时，MySQL会使用idx_1索引，因此首先锁定相关的索引记录，因为idx_1是非主键索引，为执行该语句，MySQL还会锁定主键索引 。
假设“update tab_test set state=1067,time=now () where id in (9921180)”几乎同时执行时，本语句首先锁定主键索引，由于需要更新state的值，所以还需要锁定idx_1的某些索引记录 。
这样第一条语句锁定了idx_1的记录，等待主键索引，而第二条语句则锁定了主键索引记录，而等待idx_1的记录，这样死锁就产生了 。
6、解决办法
拆分第一条sql，先查出符合条件的主键值，再按照主键更新记录：
?select id from tab_test where state=1061 and timedate_sub(now(), INTERVAL 30 minute);
?update tab_test state=1064,time=now() where id in(......);
详解MySQL（InnoDB）如何处理死锁 锁是需要事务结束后才释放mysql死锁怎么解决的 。
一个是 MVCCmysql死锁怎么解决，一个是两阶段锁协议 。
为什么要并发控制呢？是因为多个用户同时操作 MySQL 的时候，为了提高并发性能并且要求如同多个用户的请求过来之后如同串行执行的一样（为了解决脏读、不可重复读、幻读）
官方定义mysql死锁怎么解决：
两阶段锁协议是指所有事务必须分两个阶段对数据加锁和解锁，在对任何数据进行读、写操作之前，事务首先要获得对该数据的封锁；在释放一个封锁之后，事务不再申请和获得任何其他封锁 。
对应到 MySQL 上分为两个阶段mysql死锁怎么解决：
但是两阶段锁协议不要求事务必须一次将所有需要使用的数据加锁（innodb在需要的索引列数据才锁行），并且在加锁阶段没有顺序要求，所以这种并发控制方式会形成死锁 。
MySQL有两种死锁处理方式：
死锁检测 （默认开启）
死锁检测的原理是构建一个以事务为顶点、锁为边的有向图，判断有向图是否存在环，存在即有死锁 。
回滚
检测到死锁之后，选择插入更新或者删除的行数最少的事务回滚，基于 INFORMATION_SCHEMA.INNODB_TRX 表中的 trx_weight 字段来判断 。
收集死锁信息：
减少死锁：
死锁解决：
mysql发生死锁怎么解决可直接在mysql命令行执行:show engine innodb status\G; 查看造成死锁mysql死锁怎么解决的sql语句,分析索引情况,然后优化sql然后show processlist; 另外可以打开慢查询日志,linux下打开需在...
怎么解决mysql 事务出现死锁的问题这个问题，问的就有问题，你对同一条记录，同时想将use设置成1或2，业务逻辑就有问题啊 。我原来处理过类似的问题，介绍一下我的处理方式，在use表中 ， 增加一个字段b，默认值是0，在事物一开始的时候，先将你要处理的那条记录的b值，设置成1，再事物全都处理完毕后，在将1更新成0 。如果事物一开始发现这条记录的b值是1，则直接提示用户，正在对同一条数据进行处理，请稍后在试，代码里直接就return了，不往下进行 。
说白了，就是用一个字段，把一条记录锁住 ， 事物一开始先判断锁没锁，如果锁了就提示用户，如果没锁，就锁?。缓笙蛳陆?，但是，无论是正常处理完 ， 还是回滚，或者是抛出异常，都不要忘了把锁解开 。
解决一次mysql死锁问题 多线程开启事务处理 。每个事务有多个update操作和一个insert操作（都在同一张表） 。
默认隔离级别：Repeatable Read
只有hotel_id=2和hotel_id=11111mysql死锁怎么解决的数据
逻辑删除原有数据
插入新的数据
根据现有数据情况mysql死锁怎么解决，update的时候没有数据被更新
报了非常多一样的错
发现居然有死锁 。
根据常识考虑 ， mysql死锁怎么解决我每个线程（事务）更新的数据都不冲突，为什么会产生死锁？
带着这个问题，打印mysql最近一次的死锁信息
show engine innodb status
显示如下
发现事务1在等待一个锁
事务2也在等待一个锁
而且事物2持有了事物1需要的锁
关于锁的描述，出现了 lock_mode ， gap before rec，insert intention 等字眼，看不懂说明了什么？说明我关于mysql的锁相关的知识储备还不够 。那就开始调查mysql的锁相关知识 。
通过搜索引擎 ，
锁的持有兼容程度如下表
那么再回到死锁日志，可以知道 :
事务1正在获取插入意向锁
事务2正在获取插入意向锁，持有排他gap锁
再看我们上面的锁兼容表格 ， 可以知道，gap lock和insert intention lock是不兼容的
那么就可以推断出： 事务1持有gap lock，等待事务2的insert intention lock释放；事务2持有gap lock，等待事务1的insert intention lock释放，从而导致死锁 。
那么新的问题就来了，事务1的intention lock 为什么会和事务2的gap lock 有交集，或者说，事务1要插入的数据的位置为什么会被事务2给锁?。?
让我回顾一下gap lock的定义：
间隙锁，锁定一个范围，但不包括记录本身 。GAP锁的目的，是为了防止同一事务的两次当前读 ， 出现幻读的情况
那为什么是gap lock，gap lock到底是基于什么逻辑锁的记录？发现自己相关的知识储备还不够 。那就开始调查 。
调查后发现，当当前索引是一个 普通索引 的时候，会加一个gap lock来防止幻读， 此gap lock 会锁住一个左开右闭的区间 。假设索引为xx_idx（xx_id），数据分布为1,4,6,8,12 ， 当更新xx_id=9的时候，这个时候gap lock的锁定记录区间就是(8，12]，也就是锁住了xxid in (9,10,11,12)的数据，当有其他事务要插入xxid in (9,10,11,12)的数据时，就会处于等待获取锁的状态 。
ps：当前索引不是普通索引，而且是唯一索引等其他情况，请参考下面资料
MySQL 加锁处理分析
回到我自己的案例中 ， 重新屡一下事务1的执行过程：
因为普通索引
KEY hotel_date_idx ( hotel_id , rate_date )
的关系 这段sql会获取一个gap lock ， 范围(2,11111]
这段sql会获取一个insert intention lock （waiting）
再看事务2的执行过程
因为普通索引
KEY hotel_date_idx ( hotel_id , rate_date )
的关系 这段sql也会获取一个gap lock ， 范围也是(2,11111]（根据前面的知识，gap lock之间会互相兼容，可以一起持有锁的）
这段sql也会获取一个insert intention lock （waiting）
看到这里，基本也就破案了 。因为普通索引的关系 ， 事务1和事务2的gap lock的覆盖范围太广，导致其他事务无法插入数据 。
重新梳理一下：
所以从结果来看，一堆事务被回滚 ， 只有10007数据被更新成功
gap lock 导致了并发处理的死锁
在mysql默认的事务隔离级别（repeatable read）下，无法避免这种情况 。只能把并发处理改成同步处理 。或者从业务层面做处理 。
共享锁、排他锁、意向共享、意向排他
record lock、gap lock、next key lock、insert intention lock
show engine innodb status
数据库死锁处理方法mysql数据库死锁解决方法如下：
1、对于按钮等控件，点击后使其立刻失效，不让用户重复点击，避免对同时对同一条记录操作 。
2、使用乐观锁进行控制 。乐观锁大多是基于数据版本（Version）记录机制实现 。即为数据增加一个版本标识 ， 在基于数据库表的版本解决方案中，一般是 通过为数据库表增加一个“version”字段来实现 。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一 。此时，将提交数据的版本数据与数 据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据 。乐观锁机制避免了长事务中的数据 库加锁开销（用户A和用户B操作过程中，都没有对数据库数据加锁），大大提升了大并发量下的系统整体性能表现 。Hibernate 在其数据访问引擎中内置了乐观锁实现 。需要注意的是，由于乐观锁机制是在系统中实现，来自外部系统的用户更新操作不受系统的控制，因此可能会造 成脏数据被更新到数据库中 。
mysql死锁怎么解决的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于mysql死锁解决方法、mysql死锁怎么解决的信息别忘了在本站进行查找喔 。

    推荐阅读


    上一篇：济南用户小程序开发软件，济南做小程序的公司

    下一篇：如何为网吧服务器升级驱动？ 网吧服务器怎么升级驱动