Mysql 死锁

http://www.cnblogs.com/benshan/archive/2013/05/09/3068886.html

声明:以下讨论只是针对InnoDB存储引擎。


何为死锁?

死锁是对资源的分配和使用不当而造成的。是两个进程争夺某一资源而出现相互等待的现象。具体的来讲,出现死锁需要满足四个必要条件:

(1)互斥条件:每一个资源都只能被一个进程使用

(2)请求与保持条件:一个进程因请求资源而阻塞时,对已获得的资源保持不放

(3)不剥夺条件:进程已获得的资源,在末使用完之前,不能强行剥夺。

(4)循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系。

很显然,出现死锁需要两个或者两个以上的进程,换句话说,死锁发生在并发的程序中。在Mysql中,由于目前只有InnoDB引擎使用事务(InnoDB支持锁),便有了InnoDB和死锁的旷世基情。


死锁的检测

1、通过使用Show innodb status检查引擎状态 ,可以看到哪些语句产生deadlock

2、MySQL提供了一个information_schema,通过查看innodb_locks、innodb_trx、innodb_lock_waits这几个表检测死锁。

因循环等待条件而产生的死锁只有可能是四种形式:两张表两行记录交叉申请互斥锁、同一张表则存在主键索引锁冲突、主键索引锁与非聚簇索引锁冲突、锁升级导致的锁等待队列阻塞。


死锁避免

1.如果使用insert…select语句备份表格且数据量较大,在单独的时间点操作,避免与其他sql语句争夺资源,或使用select into outfile加上load data infile代替 insert…select,这样不仅快,而且不会要求锁定
2. 一个锁定记录集的事务,其操作结果集应尽量简短,以免一次占用太多资源,与其他事务处理的记录冲突。
3.更新或者删除表格数据,sql语句的where条件都是主键或都是索引,避免两种情况交叉,造成死锁。对于where子句较复杂的情况,将其单独通过sql得到后,再在更新语句中使用。
4. sql语句的嵌套表格不要太多,能拆分就拆分,避免占有资源同时等待资源,导致与其他事务冲突。
5. 对定点运行脚本的情况,避免在同一时间点运行多个对同一表进行读写的脚本,特别注意加锁且操作数据量比较大的语句。
6.应用程序中增加对死锁的判断,如果事务意外结束,重新运行该事务,减少对功能的影响。

时间: 2024-10-22 05:48:21

Mysql 死锁的相关文章

MySQL 死锁与日志二三事

最近线上 MySQL 接连发生了几起数据异常,都是在凌晨爆发,由于业务场景属于典型的数据仓库型应用,白天压力较小无法复现.甚至有些异常还比较诡异,最后 root cause 分析颇费周折.那实际业务当中咱们如何能快速的定位线上 MySQL 问题,修复异常呢?下文我会根据两个实际 case,分享下相关的经验与方法. 1.Case1:部分数据更新失败 某天渠道同学反馈某报表极个别渠道数据为 0,大部分渠道数据正常.这个数据是由一个统计程序每天凌晨例行更新的,按理来说,要么全部正常,要么全部失败,那会

MySQL死锁[转]

案例描述       在定时脚本运行过程中,发现当备份表格的sql语句与删除该表部分数据的sql语句同时运行时,mysql会检测出死锁,并打印出日志. 两个sql语句如下:       (1)insert into backup_table select * from source_table      (2)DELETE FROM source_table WHERE Id>5 AND titleWeight<32768 AND joinTime<'$daysago_1week'   

【Todo】Mysql死锁问题解决方式 &amp; 隔离级别等知识

参考了这篇文章:http://www.cnblogs.com/LBSer/p/5183300.html  <mysql死锁问题分析> 写的不错.

为什么MySQL死锁检测会严重降低TPS

在大量的客户端,更新数据表的同一行时,会造成数据库的吞吐量大幅降低. 很多数据库的前辈和同行分别通过实验和源码的方法,定位到了罪魁祸首----MySQL死锁检测 实验方式:http://blog.csdn.net/zhaiwx1987/article/details/6952285 源码方式:http://www.gpfeng.com/?p=426 请大家尤其注意这段代码 ##### lock_mutex_enter(); ut_ad(lock_table_has(thr_get_trx(thr

一个最不可思议的MySQL死锁分析

一个最不可思议的MySQL死锁分析 死锁问题背景 做MySQL代码的深入分析也有些年头了,再加上自己10年左右的数据库内核研发经验,自认为对于MySQL/InnoDB的加锁实现了如指掌,正因如此,前段时间,还专门写了一篇洋洋洒洒的文章,专门分析MySQL的加锁实现细节:<MySQL加锁处理分析>. 但是,昨天"润洁"同学在<MySQL加锁处理分析>这篇博文下咨询的一个MySQL的死锁场景,还是彻底把我给难住了.此死锁,完全违背了本人原有的锁知识体系,让我百思不得

MySQL死锁问题实例分析及解决方法

MySQL死锁问题的相关知识是本文我们主要要介绍的内容,接下来我们就来一一介绍这部分内容,希望能够对您有所帮助. 1.MySQL常用存储引擎的锁机制 MyISAM和MEMORY采用表级锁(table-level locking) BDB采用页面锁(page-level locking)或表级锁,默认为页面锁 InnoDB支持行级锁(row-level locking)和表级锁,默认为行级锁 2.各种锁特点 表级锁:开销小,加锁快;不会出现死锁;锁定粒度大,发生锁冲突的概率最高,并发度最低 行级锁

磁盘满导致mysql死锁

今天遇到一个问题,因为mysql所在机器的磁盘满了导致mysql死锁,连查询select都不行,要不是看mysql日志,还真找不到原因. 通过show processlist能看到第一条是个update语句,需要写入数据,因为磁盘满了,写入不了,导致mysql死锁. 查看mysql日志可以发现有告警日志:"[Warning] Disk is full writing './mysql-bin.000123' (Errcode: 28). Waiting for someone to free s

mysql-不恰当的update语句使用主键和索引导致mysql死锁

背景知识:MySQL有三种锁的级别:页级.表级.行级. MyISAM和MEMORY存储引擎采用的是表级锁(table-level locking):BDB存储引擎采用的是页面锁(page-level locking),但也支持表级锁:InnoDB存储引擎既支持行级锁(row-level locking),也支持表级锁,但默认情况下是采用行级锁. MySQL这3种锁的特性可大致归纳如下: 表级锁:开销小,加锁快:不会出现死锁:锁定粒度大,发生锁冲突的概率最高,并发度最低.行级锁:开销大,加锁慢:会

Mysql 死锁问题

Innodb锁系统(4) Insert/Delete 锁处理及死锁示例分析 http://mysqllover.com/?p=431 关于innodb死锁 http://afei2.sinaapp.com/?p=172 一个最不可思议的MySQL死锁分析 http://hedengcheng.com/?p=844#_Toc378337496 Mysql 死锁问题

mysql 死锁检查

mysql 死锁检查 今天看了一篇关于死锁检查的blog. Advanced InnoDB Deadlock Troubleshooting – What SHOW INNODB STATUS Doesn’t Tell You, and What Diagnostics You Should be Looking At One common cause for deadlocks when using InnoDB tables is from the existence of foreign