数据库死锁

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

今天早晨遇到问题，一个表有数据，查询能出来，插入怎么都插入不进去，update也是失败，delete也是失败。最后突然好了，也没找到原因，郁闷死。估计就是思索等问题导致，于是查了一下。下面的是复制的。转发的。 Sys.SysProcesses 系统表是一个很重要的系统视图，主要用来定位与解决Sql Server的阻塞和死锁。 MSDN：包含正在 SQL Server 实例上运行的进程的相关信息。这些进程可以是客户端进程或系统进程。 视图中主要的字段： 1. Spid：Sql Servr 会话ID 2. Kpid：Windows 线程ID 3. Blocked： 正在阻塞求情的会话 ID。如果此列为 Null，则标识请求未被阻塞 4. Waittype：当前连接的等待资源编号，标示是否等待资源，0 或 Null表示不需要等待任何资源 5. Waittime ：当前等待时间，单位为毫秒，0 表示没有等待 6. DBID：当前正由进程使用的数据库ID 7. UID：执行命令的用户ID 8. Login_time ：客户端进程登录到服务器的时间。 9. Last_batch：上次执行存储过程或Execute语句的时间。对于系统进程，将存储Sql Server 的启动时间 10.Open_tran ：进程的打开事务个数。如果有嵌套事务，就会大于1 11.Status：进程ID 状态

先查看哪些表被锁住了 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; OWNER OBJECT_NAME SESSION_ID LOCKED_MODE ------------------------------ -------------------------------------- ------- WSSB SBDA_PSHPFTDT 22 3 WSSB_RTREPOS WB_RT_SERVICE_QUEUE_TAB 24 2 WSSB_RTREPOS WB_RT_NOTIFY_QUEUE_TAB 29 2 WSSB_RTREPOS WB_RT_NOTIFY_QUEUE_TAB 39 2 WSSB SBDA_PSDBDT 47 3 WSSB_RTREPOS WB_RT_AUDIT_DETAIL 47 3 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;

先查看哪些表被锁住了 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; OWNER OBJECT_NAME SESSION_ID LOCKED_MODE ------------------------------ -------------------------------------- ------- WSSB SBDA_PSHPFTDT 22 3 WSSB_RTREPOS WB_RT_SERVICE_QUEUE_TAB 24 2 WSSB_RTREPOS WB_RT_NOTIFY_QUEUE_TAB 29 2 WSSB_RTREPOS WB_RT_NOTIFY_QUEUE_TAB 39 2 WSSB SBDA_PSDBDT 47 3 WSSB_RTREPOS WB_RT_AUDIT_DETAIL 47 3 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;

先查看哪些表被锁住了 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; OWNER OBJECT_NAME SESSION_ID LOCKED_MODE ------------------------------ -------------------------------------- ------- WSSB SBDA_PSHPFTDT 22 3 WSSB_RTREPOS WB_RT_SERVICE_QUEUE_TAB 24 2 WSSB_RTREPOS WB_RT_NOTIFY_QUEUE_TAB 29 2 WSSB_RTREPOS WB_RT_NOTIFY_QUEUE_TAB 39 2 WSSB SBDA_PSDBDT 47 3 WSSB_RTREPOS WB_RT_AUDIT_DETAIL 47 3 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;

1. MySQL 优化 - 查看执行记录 MySQL 提供了一个 EXPLAIN 命令 , 它可以 对 SELECT 语句进行分析 , 并输出 SELECT 执行的详细信息 , 以供开发人员针对性优化。 使用 explain 这个命令来查看一个这些 SQL 语句的执行计划，查看该 SQL 语句有没有使用上了索引，有没有做全表扫描，这都可以通过 explain 命令来查看。 EXPLAIN 命令用法十分简单 , 在 SELECT 语句前加上 explain 就可以了 , 例如 : 1.1 SQL 语句优化 -explain 分析问题 expain 出来的信息有 10 列，分别是 id 、 select_type 、 table 、 type 、 possible_keys 、 key 、 key_len 、 ref 、 rows 、 Extra , 下面对这些字段进行解释： id: select 查询的标识符 . 每个 select 都会自动分配一个唯一的标识符 . select_type: 表示查询的类型。 table: 输出结果集的表 type: 表示表的连接类型 possible_keys: 表示查询时，可能使用的索引 key: 表示实际使用的索引 key_len: 索引字段的长度 ref: 哪个字段或常数与 key 一起被使用 rows: 扫描出的行数 ( 估算的行数 )

都是从网上找的，只是记录一下，可能用到。 查询死锁，要在当前数据库下，否则tableName列得不到正确信息 select request_session_id spid, OBJECT_NAME(resource_associated_entity_id) tableName from sys.dm_tran_locks where resource_type='OBJECT' 杀掉死锁，spid是上面select出来的id kill spid 查询死锁的语句 DBCC INPUTBUFFER(spid) 以下是实验： 开第一个窗口执行下面语句，注意先建立表和字段 BEGIN TRANSACTION--开始事务 update t1 set f1 ='00000' where id='1' WAITFOR DELAY '02:00'; 开第二个窗口执行： select * from job where id='1' 来源： https://www.cnblogs.com/81/p/7941722.html

----查看sql死锁 CREATE procedure sp_who_lock as begin 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

在网上查看了很多死锁与阻塞的资料，为什么会出现死锁或者阻塞？ 阻塞在大数据量的数据库中经常出现，在我现在的其中一个项目出现的频率很高，根据网上查到死锁跟阻塞的资料，当时分析出来，主要是多台设备同时调用某个程序，某个程序每隔，2分钟就会去调用存储a更新现在看板里面的数据。出现阻塞的原因就是存储a。存储a以某个仓库为条件，输出数据到看板中，就会出现阻塞。因为执行这条存储耗时15s。而且该存储关联到的表起码有7,8张，而且还是数据量比较大的表。这样就就造成阻塞。现在将这次阻塞查到的一些资料+使用的东西，在此写随笔笔记。 sp_who active --看看哪个引起的阻塞，blk sp_lock --看看锁住了那个资源id，objid ，select object_name(objid) 得到 dbcc inputbuffer(@blk) -- 看看是那个语句 从上面语句就能查看到那个语句引起阻塞。就可以去优化，看看该语句设计是否可行与优化。 从网上也看到了一些死锁的资料与原作者写的一些很有用的存储过程： 如果发生死锁了，我们怎么去检测具体发生死锁的是哪条SQL语句或存储过程？ 这时我们可以使用以下存储过程来检测，就可以查出引起死锁的进程和SQL语句。SQL Server自带的系统存储过程sp_who和sp_lock也可以用来查找阻塞和死锁, 但没有这里介绍的方法好用。 use

背景 当用户并发尝试访问同一数据的时，SQL Server尝试用锁来隔离不一致的数据和使用隔离级别查询数据时控制一致性(数据该如何读取)，说起锁就会联想到事务，事务是一个工作单元，包括查询／更新数据和数据定义。 锁 锁类型 在SQL Server中，根据资源的不同，锁分为以下三种类型： 行锁：是SQL Server中数据级别中粒度最小的锁级别，行锁根据表是否存在聚集索引，分为键值锁和标识锁 页锁：针对某个数据页添加的锁，在T-SQL语句中，使用了页锁就不会在使用相同类型的行锁，反之依然，在对数据页加锁后，无法在对其添加不兼容的锁 表锁：添加表锁则无法添加与其不兼容的页å锁和行锁 锁模式 共享锁(S)：发生在数据查找之前，多个事务的共享锁之间可以共存 排他锁(X)：发生在数据更新之前，排他锁是一个独占锁，与其他锁都不兼容 更新锁(U)：发生在更新语句中，更新锁用来查找数据，当查找的数据不是要更新的数据时转化为S锁，当是要更新的数据时转化为X锁 意向锁：发生在较低粒度级别的资源获取之前，表示对该资源下低粒度的资源添加对应的锁，意向锁有分为：意向共享锁(IS) ，意向排他锁(IX)，意向更新锁(IU)，共享意向排他锁(SIX)，共享意向更新锁(SIU)，更新意向排他锁(UIX) 共享锁／排他锁／更新锁一般作用在较低级别上，例如数据行或数据页，意向锁一般作用在较高的级别上，例如数据表或数据