数据库死锁

『浅入深出』MySQL 中事务的实现 在关系型数据库中，事务的重要性不言而喻，只要对数据库稍有了解的人都知道事务具有 ACID 四个基本属性，而我们不知道的可能就是数据库是如何实现这四个属性的；在这篇文章中，我们将对事务的实现进行分析，尝试理解数据库是如何实现事务的，当然我们也会在文章中简单对 MySQL 中对 ACID 的实现进行简单的介绍。 事务其实就是并发控制的基本单位；相信我们都知道，事务是一个序列操作，其中的操作要么都执行，要么都不执行，它是一个不可分割的工作单位；数据库事务的 ACID 四大特性是事务的基础，了解了 ACID 是如何实现的，我们也就清除了事务的实现，接下来我们将依次介绍数据库是如何实现这四个特性的。 原子性 在学习事务时，经常有人会告诉你，事务就是一系列的操作，要么全部都执行，要都不执行，这其实就是对事务原子性的刻画；虽然事务具有原子性，但是原子性并不是只与事务有关系，它的身影在很多地方都会出现。 由于操作并不具有原子性，并且可以再分为多个操作，当这些操作出现错误或抛出异常时，整个操作就可能不会继续执行下去，而已经进行的操作造成的副作用就可能造成数据更新的丢失或者错误。 事务其实和一个操作没有什么太大的区别，它是一系列的数据库操作（可以理解为 SQL）的集合，如果事务不具备原子性，那么就没办法保证同一个事务中的所有操作都被执行或者未被执行了

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

DECLARE @spid INT DECLARE @blk INT DECLARE @count INT DECLARE @index INT DECLARE @lock TINYINT SET @lock=0 CREATE TABLE #temp_who_lock ( id INT IDENTITY(1, 1), spid INT, blk INT ) --if @@error<>0 return @@error INSERT INTO #temp_who_lock (spid, blk) SELECT 0, blocked FROM (SELECT FROM master..sysprocesses WHERE blocked > 0)a WHERE NOT EXISTS(SELECT FROM master..sysprocesses WHERE a.blocked = spid AND blocked > 0) UNION SELECT spid, blocked FROM master..sysprocesses WHERE blocked > 0 --if @@error<>0 return @@error SELECT @count = Count(*), @index = 1 FROM #temp_who_lock --select @count,@index -

DECLARE @spid INT DECLARE @blk INT DECLARE @count INT DECLARE @index INT DECLARE @lock TINYINT SET @lock=0 CREATE TABLE #temp_who_lock ( id INT IDENTITY(1, 1), spid INT, blk INT ) --if @@error<>0 return @@error INSERT INTO #temp_who_lock (spid, blk) SELECT 0, blocked FROM (SELECT FROM master..sysprocesses WHERE blocked > 0)a WHERE NOT EXISTS(SELECT FROM master..sysprocesses WHERE a.blocked = spid AND blocked > 0) UNION SELECT spid, blocked FROM master..sysprocesses WHERE blocked > 0 --if @@error<>0 return @@error SELECT @count = Count(*), @index = 1 FROM #temp_who_lock --select @count,@index -

电脑日益不给力，网络也随时可能断掉，用PL/SQL执行操作多多少少出现正在处理SQL语句结果程序死掉了。导致这张表被锁掉，无法执行SQL操作。 如何解除死锁？ 1）执行下面SQL，先查看哪些表被锁住了: select b.owner,b.object_name,a.session_id,a.locked_mode from v$locked_object a,dba_objects b where b.object_id = a.object_id; 2）查处引起死锁的会话寻找SID select b.username,b.sid,b.serial#,logon_time from v$locked_object a,v$session b where a.session_id = b.sid order by b.logon_time; 3）查出SID和SERIAL#： 查V$SESSION视图: SELECT SID,SERIAL#,PADDR FROM V$SESSION WHERE SID='刚才查到的SID'; 这一步将得到PADDR 4）查V$PROCESS视图: SELECT SPID FROM V$PROCESS WHERE ADDR='刚才查到的PADDR'; 这一步得到SPID 5）杀死进程 在数据库中，杀掉ORACLE进程: ALTER SYSTEM KILL

数据库会死锁吗，举一个死锁的例子，mysql 怎么解决死锁。 产生死锁的原因主要是： （1）系统资源不足。 （2） 进程运行推进的顺序不合适。 （3）资源分配不当等。 如果系统资源充足，进程的资源请求都能够得到满足，死锁出现的可能性就很低，否则就会因争夺有限的资源而陷入死锁。其次，进程运行推进顺序与速度不同，也可能产生死锁。 产生死锁的四个必要条件： （1） 互斥条件：一个资源每次只能被一个进程使用。 （2） 请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。 （3） 不剥夺条件:进程已获得的资源，在末使用完之前，不能强行剥夺。 （4） 循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系。 这四个条件是死锁的必要条件，只要系统发生死锁，这些条件必然成立，而只要上述条件之一不满足，就不会发生死锁。 这里提供两个解决数据库死锁的方法： 1）重启数据库（谁用谁知道） 2）杀掉抢资源的进程： 先查哪些进程在抢资源：SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX; 杀掉它们：Kill trx_mysql_thread_id； MYsql 的索引原理，索引的类型有哪些，如何创建合理的索引，索引如何优化。 索引是通过复杂的算法，提高数据查询性能的手段。从磁盘io到内存io的转变 普通索引，主键，唯一，单列

这个是我之前在项目组里面，有一个功能模块写了一个很复杂的sql存储过程，每次做业务都调用存储过来处理逻辑。 当多人同时做业务调用这个存储过程的时候，页面没法响应一直卡死在哪里，后面请教过专业的dba排查过问题，是存储过程里面的某部分insert,update操作导致死锁了。 现在讲排查死锁的步骤总结如下： 1、查行锁： column event format a30 column sess format a20 set linesize 150 break on id1 skip 1 select decode(request,0,'Holder:',' Waiter:') || s.inst_id || ':' || s.sid||','|| s.serial# sess, id1, id2, lmode, request, l.type, ctime, s.sql_id, s.event,s.last_call_et from gv$lock l, gv$session s where (id1, id2, l.type) in (select id1, id2, type from gv$lock where request>0) and l.sid=s.sid and l.inst_id=s.inst_id order by id1, ctime desc, request

1、死锁必要条件 2、java如何处理死锁 3、什么是重入锁、 sychronized 和 retrentlock实现区别、锁方法、锁class 4、算法题： 合并区间 快排 5、数据库 6、操作系统 7、timewait close wait 8、快排 参考： https://www.nowcoder.com/discuss/215891?type=2&order=0&pos=10&page=1 大量面试经验以及学习资料书籍请关注：AVAJ 回复"offer"进行获取 365篇大厂java面经 你想要的我这里都有 来源： https://www.cnblogs.com/DoubleP/p/11318073.html

【转】锁的分类及特性 数据库锁定机制简单来说，就是数据库为了保证数据的一致性，而使各种共享资源在被并发访问时变得有序所设计的一种规则。 对于任何一种数据库来说都需要有相应的锁定机制，所以 MySQL 自然也不能例外。 MySQL 数据库由于其自身架构的特点，存在多种数据存储引擎，每种存储引擎所针对的应用场景特点都不太一样。 为了满足各自特定应用场景的需求，每种存储引擎的锁定机制都是为各自所面对的特定场景而优化设计，所以各存储引擎的锁定机制也有较大区别。 MySQL 各存储引擎使用了三种类型（级别）的锁定机制： 表级锁定 行级锁定 页级锁定 表级锁定（table-level） 表级别的锁定是 MySQL 各存储引擎中最大颗粒度的锁定机制。该锁定机制最大的特点是实现逻辑非常简单，带来的系统负面影响最小。 所以获取锁和释放锁的速度很快。由于表级锁定一次会将整个表锁定，所以可以很好的避免困扰我们的死锁问题。 当然，锁定颗粒度大所带来最大的负面影响就是出现锁定资源争用的概率也会最高，致使并大度大打折扣。 使用表级锁定的主要是 MyISAM，MEMORY，CSV 等一些非事务性存储引擎。　　 行级锁定（row-level） 行级锁定最大的特点就是锁定对象的颗粒度很小，也是目前各大数据库管理软件所实现的锁定颗粒度最小的。 由于锁定颗粒度很小，所以发生锁定资源争用的概率也最小