MySQL死锁问题的相关知识是本文我们主要要介绍的内容，接下来我们就来一一介绍这部分内容，希望能够对您有所帮助。
1、MySQL常用存储引擎的锁机制
MyISAM和MEMORY采用表级锁(table-level locking)
BDB采用页面锁(page-level locking)或表级锁，默认为页面锁
InnoDB支持行级锁(row-level locking)和表级锁，默认为行级锁
2、各种锁特点
表级锁：开销小，加锁快;不会出现死锁;锁定粒度大，发生锁冲突的概率最高，并发度最低
行级锁：开销大，加锁慢;会出现死锁;锁定粒度最小，发生锁冲突的概率最低，并发度也最高
页面锁：开销和加锁时间界于表锁和行锁之间;会出现死锁;锁定粒度界于表锁和行锁之间，并发度一般
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 time < date_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 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 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 time < date_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 time < date_sub(now(), INTERVAL 30 minute);
?update tab_test state=1064,time=now() where id in(......);
2. sqldeveloper怎么杀死死锁的表
尝试在sqlplus中通过sql命令进行删除，如果能够删除成功，则万事大吉。
但通常情况下，出现死锁时，想通过命令行或者通过oracle的管理工具删除有死锁的session，oracle只会将该session标记为killed，但无法清除掉，往往需要通过第二步在操作系统层级进行删除。
altersystemkillsession29，57107。--删除进程，如已经删除过，则会报ora-00031的错误，否则oracle会将该session标记为killed状态，等待一段时间看能否会自动消失，如长时间消失不掉，则需要做后续步骤。一些ORACLE中的进程被杀掉后，状态被置为killed，但是锁定的资源很长时间不释放，有时实在没办法，只好重启数据库。现在提供一种方法解决这种问题，那就是在ORACLE中杀不掉的，在OS一级再杀。
3. SQL数据库总是假死或死锁。
建议：
1、使用事件探查器，跟踪一下SQL在死锁之前执行了哪些SQL语句
2、多数死锁是因为程序没有经过严格的测试造成的
3、少部分原因是因为触发器嵌套造成的，SQL有内部机制，当嵌套到一定的层级，就自动终止掉相关的进程
愿早日解决问题
4. 如何解除sql server数据库数据被锁定
1.2 事务的ACID原则
1.3 锁是关系数据库很重要的一部分, 数据库必须有锁的机制来确保数据的完整和一致性. 1.3.1 SQL Server中可以锁定的资源:
1.3.2 锁的粒度:
1.3.3 锁的升级: 锁的升级门限以及锁升级是由系统自动来确定的，不需要用户设置. 1.3.4 锁的类型: (1) 共享锁: 共享锁用于所有的只读数据操作. (2) 修改锁: 修改锁在修改操作的初始化阶段用来锁定可能要被修改的资源，这样可以避免使用共享锁造成的死锁现象 (3) 独占锁: 独占锁是为修改数据而保留的。它所锁定的资源，其他事务不能读取也不能修改。独占锁不能和其他锁兼容。 (4) 架构锁 结构锁分为结构修改锁(Sch-M)和结构稳定锁(Sch-S)。执行表定义语言操作时，SQL Server采用Sch-M锁，编译查询时，SQL Server采用Sch-S锁。 (5) 意向锁 意向锁说明SQL Server有在资源的低层获得共享锁或独占锁的意向。 (6) 批量修改锁 批量复制数据时使用批量修改锁 1.3.4 SQL Server锁类型 (1) HOLDLOCK: 在该表上保持共享锁，直到整个事务结束，而不是在语句执行完立即释放所添加的锁。 (2) NOLOCK：不添加共享锁和排它锁，当这个选项生效后，可能读到未提交读的数据或“脏数据”，这个选项仅仅应用于SELECT语句。 (3) PAGLOCK：指定添加页锁(否则通常可能添加表锁)。 (4) READCOMMITTED用与运行在提交读隔离级别的事务相同的锁语义执行扫描。默认情况下，SQL Server 2000 在此隔离级别上操作。 (5) READPAST: 跳过已经加锁的数据行，这个选项将使事务读取数据时跳过那些已经被其他事务锁定的数据行，而不是阻塞直到其他事务释放锁， READPAST仅仅应用于READ COMMITTED隔离性级别下事务操作中的SELECT语句操作。 (6) READUNCOMMITTED：等同于NOLOCK。 (7) REPEATABLEREAD：设置事务为可重复读隔离性级别。 (8) ROWLOCK：使用行级锁，而不使用粒度更粗的页级锁和表级锁。
5. 如何处理SQL Server死锁问题
1)
预防死锁。
这是一种较简单和直观的事先预防的方法。方法是通过设置某些限制条件，去破坏产生死锁的四个必要条件中的一个或者几个，来预防发生死锁。预防死锁是一种较易实现的方法，已被广泛使用。但是由于所施加的限制条件往往太严格，可能会导致系统资源利用率和系统吞吐量降低。
2)
避免死锁。
该方法同样是属于事先预防的策略，但它并不须事先采取各种限制措施去破坏产生死锁的的四个必要条件，而是在资源的动态分配过程中，用某种方法去防止系统进入不安全状态，从而避免发生死锁。
3)检测死锁。
这种方法并不须事先采取任何限制性措施，也不必检查系统是否已经进入不安全区，此方法允许系统在运行过程中发生死锁。但可通过系统所设置的检测机构，及时地检测出死锁的发生，并精确地确定与死锁有关的进程和资源，然后采取适当措施，从系统中将已发生的死锁清除掉。
4)解除死锁。
这是与检测死锁相配套的一种措施。当检测到系统中已发生死锁时，须将进程从死锁状态中解脱出来。常用的实施方法是撤销或挂起一些进程，以便回收一些资源，再将这些资源分配给已处于阻塞状态的进程，使之转为就绪状态，以继续运行。死锁的检测和解除措施，有可能使系统获得较好的资源利用率和吞吐量，但在实现上难度也最大。
由上面4中处理死锁的办法看，其中检测死锁和解除死锁是Lock
Monitor的事，作为DBA或数据库开发人员，处理死锁要放在预防和避免死锁上。
预防死锁
预防死锁就是破坏四个必要条件中的某一个和几个，使其不能形成死锁。有如下几种办法
1)破坏互斥条件
破坏互斥条件有比较严格的限制,在SQL
Server中，如果业务逻辑上允许脏读，则可以通过将隔离等级改为未提交读或使用索引提示。这样使得读取不用加S锁，从而避免了和其它查询所加的与S锁不兼容的锁互斥，进而减少了死锁出现的概率。
2)破坏请求和等待条件
这点由于事务存在原子性，是不可破坏的，因为解决办法是尽量的减少事务的长度，事务内执行的越快越好。这也可以减少死锁出现的概率。
3)破坏不剥夺条件
由于事务的原子性和一致性，不剥夺条件同样不可破坏。但我们可以通过增加资源和减少资源占用两个角度来考虑。
增加资源：比如说通过建立非聚集索引，使得有了额外的资源，查询很多时候就不再索要锁基本表，转而锁非聚集索引，如果索引能够“覆盖(Cover)”查询，那更好不过。因此索引Include列不仅仅减少书签查找来提高性能，还能减少死锁。增加资源还可以通过SQL
Server
2005之后的行版本控制进行，但这种方式并不推荐，在此不再详细讨论。
减少资源占用:比如说查询时，能用select
col1,col2这种方式，就不要用select
*
.这有可能带来不必要的书签查找
6. 怎么样解决MSSQL产生死锁的问题
一、 什么是死锁
死锁是指两个或两个以上的进程在执行过程中,因争夺资源而造成的一种互相等待的现象,若无外力作用,它们都将无法推进下去.此时称系统处于死锁状态或系统产生了死锁,这些永远在互相等的进程称为死锁进程.
二、 死锁产生的四个必要条件
互斥条件：指进程对所分配到的资源进行排它性使用，即在一段时间内某资源只由一个进程占用。如果此时还有其它进程请求资源，则请求者只能等待，直至占有资源的进程用毕释放
请求和保持条件：指进程已经保持至少一个资源，但又提出了新的资源请求，而该资源已被其它进程占有，此时请求进程阻塞，但又对自己已获得的其它资源保持不放
不剥夺条件：指进程已获得的资源，在未使用完之前，不能被剥夺，只能在使用完时由自己释放
环路等待条件：指在发生死锁时，必然存在一个进程——资源的环形链，即进程集合{P0，P1，P2，···，Pn}中的P0正在等待一个P1占用的资源；P1正在等待P2占用的资源，……，Pn正在等待已被P0占用的资源
这四个条件是死锁的必要条件，只要系统发生死锁，这些条件必然成立，而只要上述条件之一不满足，就不会发生死锁。
三、 如何处理死锁
1) 锁模式
共享锁（S）
由读操作创建的锁，防止在读取数据的过程中，其它事务对数据进行更新；其它事务可以并发读取数据。共享锁可以加在表、页、索引键或者数据行上。在SQL SERVER默认隔离级别下数据读取完毕后就会释放共享锁，但可以通过锁提示或设置更高的事务隔离级别改变共享锁的释放时间。
2.独占锁(X)
对资源独占的锁，一个进程独占地锁定了请求的数据源，那么别的进程无法在此数据源上获得任何类型的锁。独占锁一致持有到事务结束。
3.更新锁(U)
更新锁实际上并不是一种独立的锁，而是共享锁与独占锁的混合。当SQL SERVER执行数据修改操作却首先需要搜索表以找到需要修改的资源时，会获得更新锁。
更新锁与共享锁兼容，但只有一个进程可以获取当前数据源上的更新锁，
其它进程无法获取该资源的更新锁或独占锁，更新锁的作用就好像一个序列化阀门（serialization gate），将后续申请独占锁的请求压入队列中。持有更新锁的进程能够将其转换成该资源上的独占锁。更新锁不足以用于更新数据—实际的数据修改仍需要用到独占锁。对于独占锁的序列化访问可以避免转换死锁的发生，更新锁会保留到事务结束或者当它们转换成独占锁时为止。
4. 意向锁(IX,IU,IS)
意向锁并不是独立的锁定模式，而是一种指出哪些资源已经被锁定的机制。
如果一个表页上存在独占锁，那么另一个进程就无法获得该表上的共享表锁，这种层次关系是用意向锁来实现的。进程要获得独占页锁、更新页锁或意向独占页锁，首先必须获得该表上的意向独占锁。同理，进程要获得共享行锁，必须首先获得该表的意向共享锁，以防止别的进程获得独占表锁。
5. 特殊锁模式(Sch_s,Sch_m,BU)
SQL SERVER提供3种额外的锁模式：架构稳定锁、架构修改锁、大容量更新锁。
6.转换锁(SIX,SIU,UIX)
转换锁不会由SQL SERVER 直接请求，而是从一种模式转换到另一种模式所造成的。SQL SERVER 2008支持3种类型的转换锁：SIX、SIU、UIX.其中最常见的是SIX锁，如果事务持有一个资源上的共享锁（S），然后又需要一个IX锁，此时就会出现SIX。
7.键范围锁
键范围锁是在可序列化隔离级别中锁定一定范围内数据的锁。保证在查询数据的键范围内不允许插入数据。
http://www.cnblogs.com/qiaokai/p/5344252.html
7. 在数据库中解决死锁的常用方法有哪些
1、要求每个事务一次就将所有要使用的数据全部加锁,否则不能执行。
2、采用按序加锁法.预先规定一个封锁顺序,所有的事务都必须按这个顺序对数据执行封锁。
3、不采取任何措施来预防死锁的发生,而是周期性地检查系统中是否有死锁.如果发现死锁就设法解除。