数据库死锁

参考了这篇文章： http://www.cnblogs.com/LBSer/p/5183300.html 《 mysql死锁问题分析 》 写的不错。 如果Mysql死锁，会报出： 1.1 死锁成因&&检测方法 我们mysql用的存储引擎是innodb，从日志来看，innodb主动探知到死锁，并回滚了某一苦苦等待的事务。问题来了，innodb是怎么探知死锁的？ 直观方法是在两个事务相互等待时，当一个等待时间超过设置的某一阀值时，对其中一个事务进行回滚，另一个事务就能继续执行。这种方法简单有效，在innodb中，参数innodb_lock_wait_timeout用来设置超时时间。 仅用上述方法来检测死锁太过被动，innodb还提供了 wait-for graph算法 来主动进行死锁检测，每当加锁请求无法立即满足需要并进入等待时，wait-for graph算法都会被触发。 1.2 innodb隔离级别、索引与锁 1.2.1 锁与索引的关系 假设我们有一张消息表（msg），里面有3个字段。假设id是主键，token是非唯一索引，message没有索引。 id: bigint token: varchar(30) message: varchar(4096) innodb对于主键使用了 聚簇索引 ，这是一种数据存储方式，表数据是和主键一起存储，主键索引的叶结点存储行数据。对于普通索引

所谓死锁：是指两个或两个以上的进程在执行过程中，因争夺资源而造成的一种互相等待的现象 一.出现死锁的原因 　　（1）交叉锁可导致程序出现死锁 　　　　线程A持有R1的锁等待获取R2的锁，线程B持有R2的锁等待R1的锁，这种情况最容易导致程序发生死锁的问题 　　（2）内存不足 　　　　当并发请求系统可用内存时，如果此时系统内存不足，则可能会出现锁的情况。两个线程T1和T2，执行某个任务，其中T1已经获取了10MB内存，T2获取了20MB内存，如果每个线程的执行单元都需要30MB的内存，但是剩余可用的 　　　 内存刚好是20MB，那么两个线程有可能都在等待彼此能够释放内存资源 　　（3）一问一答式的数据交换 　　　　服务端开启某个端口，等待客户端访问，客户端发送请求立即等待接收，由于某种原因服务端错过了客户端的请求，仍然在等待一问一答的数据交互，此时服务端和客户端都在等待对方发送数据。 　　（4）数据库锁 　　　　无论是数据库表级别的锁，还是行级别的锁，比如某个线程执行for update语句退出了事物，其它此案成访问该数据库都将陷入死锁 　　（5）文件锁 　　　　某线程获得文件锁意外退出，其它读取该文件的线程也将进入死锁直到系统释放文件句柄资源 　　（6）死循环引起的死锁 　　　　程序由于代码原因或者某些异常处理不当，进入死循环，虽然查看堆栈信息不会出现任何死锁的迹象，但是程序不工作

为什么要有锁？ 我们都是知道，数据库中锁的设计是解决多用户同时访问共享资源时的并发问题。在访问共享资源时，锁定义了用户访问的规则。根据加锁的范围，MySQL 中的锁可大致分成全局锁，表级锁和行锁三类。在本篇文章中，会依次介绍三种类型的锁。在阅读本篇文章后，应该掌握如下的内容： 为什么要在备份时使用全局锁？ 为什么推荐使用 InnoDB 作为引擎进行备份？ 设置全局只读的方法 表级锁的两种类型 MDL 导致数据库挂掉的问题 如何利用两段锁协议减少锁冲突 如何解决死锁 对于热点表，如何避免死锁检测的损耗？ 全局锁 什么是全局锁？ 全局锁会让整个库处于只读状态，其他线程语句（DML，DDL，更新事务类）的语句都被会阻塞。 使用全局锁的场景 在做全库逻辑备份时，会把整库进行 select 然后保存成文本。 为什么要使用全局锁？ 想象这样一个场景，要备份一个购买系统，其中购买操作设计到更新账号余额表和用户课程表。 现在进行逻辑备份，在备份过程中，一位用户购买了一门课程，这时需要在余额表扣掉余额，然后在购买的课程中加上一门课。正确的顺序肯定是先进行购买操作，减少余额和增加课程然后在进行备份。但却有可能出现这样的问题： 如果在时间顺序上先备份余额表 (u_account)，然后用户购买(操作两张表)，再备份用户课程表(u_course)？ 这时用备份的数据做恢复时，会发现用户没花钱却买了一堂课

http://luohonghong.blog.163.com/blog/static/78312058201142411533316/ SQLServer查看和解决死锁的方法 2011-05-24 11:05:33 | 分类： SQL | 字号 订阅 在master数据库中新建以下存储过程 --处理死锁 -- 查看当前进程,或死锁进程,并能自动杀掉死进程 -- 因为是针对死的,所以如果有死锁进程,只能查看死锁进程 -- 当然,你可以通过参数控制,不管有没有死锁,都只查看死锁进程 --调用示例 exec p_lockinfo create proc [dbo].[p_lockinfo] @kill_lock_spid bit=1, --是否杀掉死锁的进程,1 杀掉, 0 仅显示 @show_spid_if_nolock bit=1 --如果没有死锁的进程,是否显示正常进程信息,1 显示,0 不显示 as declare @count int,@s nvarchar(1000),@i int select id=identity(int,1,1),标志, 进程ID=spid,线程ID=kpid,块进程ID=blocked,数据库ID=dbid, 数据库名=db_name(dbid),用户ID=uid,用户名=loginame,累计CPU时间=cpu, 登陆时间=login_time

今天新增数据新增不了 然后也不进去断点 架构师一眼就看出来是不是数据库锁住了 让我们排查下 我立马百度： 1，查看那个表死锁 select object_name ( resource_associated_entity_id ) as tableName , request_session_id as pid from sys . dm_tran_locks where resource_type = 'OBJECT' 2，结束死锁的进程 kill 70 --pid 瞬间解决 同事说好了 我假装如无其事 反问：哦是吗我不信 深藏自己的功与名 https://www.cnblogs.com/zique/p/9438663.html 来源： CSDN 作者： 周杰伦本人 链接： https://blog.csdn.net/sdaujsj1/article/details/103881770

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 、 T2 表示两个任务； R1 和

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> waiting for ndbcluster qlobal schema lock; MySQL + PHP的模式在大并发压力下经常会导致MySQL中存在大量僵死进程，导致服务挂死。为了自动干掉这些进程，弄了个脚本，放在服务器后台通过crontab自动执行。发现这样做了以后，的确很好的缓解了这个问题。把这个脚本发出来和大家Share. 根据自己的实际需要，做了一些修改： SHELL脚本:mysqld_kill_sleep.sh #!/bin/sh mysql_pwd=”root的密码" mysqladmin_exec="/usr/local/bin/mysqladmin" mysql_exec="/usr/local/bin/mysql" mysql_timeout_dir="/tmp" mysql_timeout_log="$mysql_timeout_dir/mysql_timeout.log" mysql_kill_timeout_sh="$mysql_timeout_dir/mysql_kill_timeout.sh" mysql_kill_timeout_log="$mysql_timeout_dir/mysql_kill_timeout.log" $mysqladmin_exec -uroot -p

mark下自己近期在电商开发中遇到的一个问题－数据库死锁及其排查过程。 先抛一个业务报错日志做为这次梳理的开始 上图是我接收到的错误报警，SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction，错误信息显示我们业务中有一条数据库操作遇到了死锁情况。接下来就开始我们的追查之旅。 1.执行“show engine innodb status”获取INNODB引擎当前信息（ show engine innodb status 详细介绍 ） ------------------------ LATEST DETECTED DEADLOCK ------------------------ 2017-01-04 09:25:17 7f553477d700 *** (1) TRANSACTION: TRANSACTION 124378994, ACTIVE 0.007 sec starting index read mysql tables in use 1, locked 1 LOCK WAIT 4 lock struct(s), heap size 1184, 8 row lock(s), undo log entries

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 前言： 由于网站访问压力的问题，综合分析各种因素后结合实际情况，采用数据库读写分离模式来解决当前问题。实际方案中采用“事务发布”模式实现主数据库和只读数据库的同步，其中： 　　　　发布服务器1台：sql2008，推送订阅模式 　　　　订阅服务器2台：sql2008 问题： 以上方案后实施后，数据同步正常，但从日志中发现了死锁情况。错误提示如：事务(进程 ID *)与另一个进程被死锁在 锁 资源上，并且已被选作死锁牺牲品。请重新运行该事务。 查询一些资料后，确定是数据同步的同时资源被锁，同时用户访问页面请求，导致死锁产生，按照事务优先级，应用程序产生死锁。 解决方法： 找到大致思路后，查询了一些资料，大部分资料显示是死锁如何产生，如果跟踪日志，然后根据日志优化查询等方向，尝试一些方案后死锁减少，但并没有彻底解决，最后转换思路，从项目实际情况来看，主要是资讯信息的查询，对查询结果的安全性要求相对不高，所以可以接受“脏”数据的情况，在某种情况下又能提升查询的性能，于是在一些查询频繁和数据量比较大的几个表的select语句中加入with(nolock)，死锁问题彻底解决。 建议： 处理一个数据库死锁的异常时候，其中一个建议就是使用 NOLOCK 或者 READPAST，对于非银行等严格要求事务的行业

1. 2 MySQL InnoDB 锁的基本类型 https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html 官网把锁分成了 8 类。所以我们把前面的两个行级别的锁（Shared and Exclusive Locks），和两个表级别的锁（Intention Locks）称为锁的基本模式。 后面三个 Record Locks、Gap Locks、Next-Key Locks，我们把它们叫做锁的算法， 也就是分别在什么情况下锁定什么范围。 2.1 锁的粒度 我们讲到 InnoDB 里面既有行级别的锁，又有表级别的锁，我们先来分析一下这两 种锁定粒度的一些差异。 表锁，顾名思义，是锁住一张表；行锁就是锁住表里面的一行数据。锁定粒度，表 锁肯定是大于行锁的。 那么加锁效率，表锁应该是大于行锁还是小于行锁呢？大于。为什么？表锁只需要 直接锁住这张表就行了，而行锁，还需要在表里面去检索这一行数据，所以表锁的加锁 效率更高。 第二个冲突的概率？表锁的冲突概率比行锁大，还是小？ 大于，因为当我们锁住一张表的时候，其他任何一个事务都不能操作这张表。但是 我们锁住了表里面的一行数据的时候，其他的事务还可以来操作表里面的其他没有被锁 定的行，所以表锁的冲突概率更大。 表锁的冲突概率更大，所以并发性能更低，这里并发性能就是小于。 nnoDB