数据库死锁

Oracle死锁查询及处理 转载 2011年08月13日 11:43:37 一、数据库死锁的现象 程序在执行的过程中，点击确定或保存按钮，程序没有响应，也没有出现报错。 二、死锁的原理 当对于数据库某个表的某一列做更新或删除等操作，执行完毕后该条语句不提 交，另一条对于这一列数据做更新操作的语句在执行的时候就会处于等待状态， 此时的现象是这条语句一直在执行，但一直没有执行成功，也没有报错。 三、死锁的定位方法 通过检查数据库表，能够检查出是哪一条语句被死锁，产生死锁的机器是哪一台。 1）用dba用户执行以下语句 select username,lockwait,status,machine,program from v$session where sid in (select session_id from v$locked_object) 如果有输出的结果，则说明有死锁，且能看到死锁的机器是哪一台。字段说明： Username：死锁语句所用的数据库用户； Lockwait：死锁的状态，如果有内容表示被死锁。 Status： 状态，active表示被死锁 Machine： 死锁语句所在的机器。 Program： 产生死锁的语句主要来自哪个应用程序。 2）用dba用户执行以下语句，可以查看到被死锁的语句。 select sql_text from v$sql where hash

一、概述 mysql的锁分为表锁和行锁两种，其中myisam引擎用的是表锁， innoDB默认的使用是行锁， 其他情况是表锁。 两种锁的优缺点： 表级锁：加锁速度快，开销小。不会出现死锁的情况，粒度大，发生锁冲突的概率最高，并发度最低。 行级锁：加锁速度慢，开销大。 会出现死锁的情况，粒度小， 发生锁冲突的概率最小，并发度最高 页面锁：介于以上两者之间 无法确定哪种锁更合适： 表级锁更适合查询为主，只有少量按索引更新数据的应用，如web应用。 行级锁适合有大量索引并发更新少量不同的数据，同时有并发查询的应用，如一些在线的事物系统。 二、MyIsam存储引擎 只支持表锁。 查询表级锁的争用情况： table_locks_waited 和 table_locks_immediate 1. mysql> show status like 'table%'; 2. +-----------------------+-------+ 3. | Variable_name | Value | 4. +-----------------------+-------+ 5. | Table_locks_immediate | 2979 | 6. | Table_locks_waited | 0 | 2.1、表级锁的锁模式 两种模式：表共享读锁，表独占写锁 分析：

SQL Server死锁总结 1. 死锁原理 根据操作系统中的定义：死锁是指在一组进程中的各个进程均占有不会释放的资源，但因互相申请被其他进程所站用不会释放的资源而处于的一种永久等待状态。 死锁的四个必要条件： 互斥条件 (Mutual exclusion) ：资源不能被共享，只能由一个进程使用。 请求与保持条件 (Hold and wait) ：已经得到资源的进程可以再次申请新的资源。 非剥夺条件 (No pre-emption) ：已经分配的资源不能从相应的进程中被强制地剥夺。 循环等待条件 (Circular wait) ：系统中若干进程组成环路，该环路中每个进程都在等待相邻进程正占用的资源。 对应到 SQL Server 中，当在两个或多个任务中，如果每个任务锁定了其他任务试图锁定的资源，此时会造成这些任务永久阻塞，从而出现死锁；这些资源可能是 ：单行 (RID ，堆中的单行 ) 、索引中的键 (KEY ，行锁 ) 、页 (PAG ， 8KB) 、区结构 (EXT ，连续的 8 页 ) 、堆或 B 树 (HOBT) 、表 (TAB ，包括数据和索引 ) 、文件 (File ，数据库文件 ) 、应用程序专用资源 (APP) 、元数据 (METADATA) 、分配单元 (Allocation_Unit) 、整个数据库 (DB) 。 一个死锁示例如下图所示： 说明： T1 、

前段时间提到的"sql server 2005 死锁解决探索"，死锁严重，平均每天会发生一次死锁，在解决和处理SQL server2005死锁中查了很多资料和想了很多办法， 对为何出现死锁和怎样较少死锁有了进一步认识，在这里和大家一起分享： sql server 锁类型 在数据库中主要存在两种锁: S(共享锁）和X(排他锁） S(共享锁）：在执行查询数据时，sql server会将行锁定，这时只能查询数据，删，改被阻塞， X(排他锁）：在插入和删除数据时，将行锁定，这时增，删，改都被阻塞 以上两种锁都会引起死锁： 死锁定义：在两个或多个任务中，如果每个任务锁定了其他任务试图锁定的资源，此时会造成这些任务永久阻塞，从而出现死锁 这里模拟一下死锁环境： 建立环境： ----死锁例子,建立表数据 create table [dbo].[[zping.com1]]]( A varchar(2) ,B varchar(2) ,C varchar(2)) --插入数据 insert into [dbo].[[zping.com1]]] select 'a1','b1','c1' union all select 'a2','b2','c2' union all select 'a3','b3','c3' --建立表数据 create table [dbo].[[zping.com2]]] (D

多线程经典面试题60问。 历史文章： dubbo&zookeeper55道高频面试题（附加答案） SpringCloud&SpringBoot经典面试题（附加答案） 1.什么是活锁、饥饿、无锁、死锁？ 死锁、活锁、饥饿是关于多线程是否活跃出现的运行阻塞障碍问题，如果线程出现 了这三种情况，即线程不再活跃，不能再正常地执行下去了。 死锁 死锁是多线程中最差的一种情况，多个线程相互占用对方的资源的锁，而又相互等 对方释放锁，此时若无外力干预，这些线程则一直处理阻塞的假死状态，形成死锁。 举个例子，A 同学抢了 B 同学的钢笔，B 同学抢了 A 同学的书，两个人都相互占 用对方的东西，都在让对方先还给自己自己再还，这样一直争执下去等待对方还而 又得不到解决，老师知道此事后就让他们相互还给对方，这样在外力的干预下他们 才解决，当然这只是个例子没有老师他们也能很好解决，计算机不像人如果发现这 种情况没有外力干预还是会一直阻塞下去的。 活锁 活锁这个概念大家应该很少有人听说或理解它的概念，而在多线程中这确实存在。 活锁恰恰与死锁相反，死锁是大家都拿不到资源都占用着对方的资源，而活锁是拿 到资源却又相互释放不执行。当多线程中出现了相互谦让，都主动将资源释放给别 的线程使用，这样这个资源在多个线程之间跳动而又得不到执行，这就是活锁。 饥饿 我们知道多线程执行中有线程优先级这个东西

一、MySQL 锁类型 1. MySQL 常用存储引擎的锁机制 MyISAM和MEMORY采用表级锁(table-level locking) BDB采用页面锁(page-level locking)或表级锁，默认为页面锁 InnoDB支持行级锁(row-level locking)和表级锁,默认为行级锁 2. 各种锁特点 表级锁：开销小,加锁快;不会出现死锁;锁定粒度大,发生锁冲突的概率最高,并发度最低 行级锁：开销大,加锁慢;会出现死锁;锁定粒度最小,发生锁冲突的概率最低,并发度也最高 页面锁：开销和加锁时间界于表锁和行锁之间;会出现死锁;锁定粒度界于表锁和行锁之间,并发度一般 3. 各种锁的适用场景 表级锁更适合于以查询为主,只有少量按索引条件更新数据的应用,如Web应用 行级锁则更适合于有大量按索引条件并发更新数据,同时又有并发查询的应用,如一些在线事务处理系统。 二、 MySQL 死锁产生原因 所谓死锁<DeadLock>：是指两个或两个以上的进程在执行过程中,因争夺资源而造成的一种互相等待的现象,若无外力作用，它们都将无法推进下去.此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程称为死锁进程。表级锁不会产生死锁.所以解决死锁主要还是针对于最常用的InnoDB。 死锁的关键在于：两个(或以上)的Session加锁的顺序不一致。

本文主要涉及以下几个个部分： 1. 为什么要加锁 2. 锁的分类 3. 常见语句的加锁分析 4. 如何分析死锁 5. 如何预防死锁 先列出本地的运行环境 数据库版本是5.7，隔离级别是Repeatable-Read(可重复读)，不同的数据库版本和隔离级别对语句的执行结果影响很大。所以需要说明版本和隔离级别 一、为什么要加锁 数据库是一个多用户使用的共享资源。当多个用户并发地存取数据时，在数据库中加锁是为了保证数据库的一致性。 数据库有ACID原则，其中I是隔离性， 脏读：读未提交的数据 不可重复读：读已修改的数据 虚读：读提交了插入/删除的数据 事务隔离机制 和标准SQL规范相比，MySQL中可重复读解决了幻读，实现了串行化隔离级别的功能，同时没有严重影响并发。是通过加锁、阻止插入新数据，来解决幻读的。 二、锁的分类 锁 我们听说过读锁、写锁、共享锁、互斥锁、行锁等等各种名词，简单对这些锁进行了分类。 锁的分类 加锁机制： 1、乐观锁：先修改，保存时判断是够被更新过，应用级别 2、悲观锁：先获取锁，再操作修改，数据库级别 锁粒度： 表级锁：开销小，加锁快，粒度大，锁冲突概率大，并发度低，适用于读多写少的情况。 页级锁：BDB存储引擎 行级锁：Innodb存储引擎，默认选项 兼容性： S锁，也叫做读锁、共享锁，对应于我们常用的 select * from users where id

线上某服务时不时报出如下异常（大约一天二十多次）：“Deadlock found when trying to get lock;”。 Oh, My God! 是死锁问题。尽管报错不多，对性能目前看来也无太大影响，但还是需要解决，保不齐哪天成为性能瓶颈。 为了更系统的分析问题，本文将从死锁检测、索引隔离级别与锁的关系、死锁成因、问题定位这五个方面来展开讨论。 图1 应用日志 1 死锁是怎么被发现的？ 1.1 死锁成因&&检测方法 左图那两辆车造成死锁了吗？不是！右图四辆车造成死锁了吗？是！ 图2 死锁描述 我们mysql用的存储引擎是innodb，从日志来看，innodb主动探知到死锁，并回滚了某一苦苦等待的事务。问题来了，innodb是怎么探知死锁的？ 直观方法是在两个事务相互等待时，当一个等待时间超过设置的某一阀值时，对其中一个事务进行回滚，另一个事务就能继续执行。这种方法简单有效，在innodb中，参数innodb_lock_wait_timeout用来设置超时时间。 仅用上述方法来检测死锁太过被动，innodb还提供了wait-for graph算法来主动进行死锁检测，每当加锁请求无法立即满足需要并进入等待时，wait-for graph算法都会被触发。 1.2 wait-for graph原理 我们怎么知道上图中四辆车是死锁的？他们相互等待对方的资源，而且形成环路

死锁处理流程： show full processlist; # 获得当前所有数据库连接 select id, db, user, host, command, time, state, info from information_schema.processlist where command != 'Sleep' order by time desc\G; show engine innodb status; # 查看innodb的事务. select * from information_schema.innodb_trx;# 查找当前事务 select * from information_schema.innodb_locks;# 查找当前已经锁定的事务 select * from information_schema.innodb_lock_waits;# 查找当前等待锁的事务 # 联系业务，确定是否可杀。 kill 线程id;# 若是lock tables语句锁定，则比较麻烦 来源： https://www.cnblogs.com/igoodful/p/11962303.html

单场景：单个功能的场景（重要的，用得多的，主要流程，和钱相关的，测性能、测目标） 混合场景：多个功能的场景（测死锁，线程死锁，数据库死锁） 稳定性场景：内存溢出 单场景、混合场景，一次性能测试一般跑15分钟。 稳定性测试场景一般跑：n*12小时 系统平均无故障时间就是通过稳定性场景跑。 来源： https://www.cnblogs.com/huainanhai/p/11955022.html