深入浅出解析mssql在高频,高并发访问时键查找死锁问题

死锁对于DBA或是数据库开发人员而言并不陌生,它的引发多种多样,一般而言,数据库应用的开发者在设计时都会有一定的考量进而尽量避免死锁的产生.但有时因为一些特殊应用场景如高频查询,高并发查询下由于数据库设计的潜在问题,一些不易捕捉的死锁可能出现从而影响业务.这里为大家介绍由于设计问题引起的键查找死锁及相关的解决办法.

这里我们在测试的同时开启trace profiler跟踪死锁视图(locks:deadlock graph).(当然也可以开启跟踪标记,或者应用扩展事件(xevents)等捕捉死锁)

创建测试对象code

create table testklup
(
clskey int not null,
nlskey int not null,
cont1 int not null,
cont2 char(3000)
)

create unique clustered index inx_cls on testklup(clskey)

create unique nonclustered index inx_nlcs on testklup(nlskey) include(cont1)

insert into testklup select 1,1,100,'aaa'
insert into testklup select 2,2,200,'bbb'
insert into testklup select 3,3,300,'ccc'

开启会话1 模拟高频update操作

----模拟高频update操作

 declare @i int
set @i=100
while 1=1
 begin
 update testklup set cont1=@i
 where clskey=1
 set @i=@i+1
 end

开启会话2 模拟高频select操作

----模拟高频select操作

declare @cont2 char(3000)
while 1=1
begin
  select @cont2=cont2 from testklup where nlskey=1
end

此时开启会话2执行一小段时间时我们就可以看到类似错误信息:图1-1

图1-1

而在我们开启的跟踪中捕捉到了如下的死锁图.图1-2

图1-2

死锁分析:可以看出由于读进程(108)请求写进程(79)持有的X锁被阻塞的同时,写进程(79)又申请读进程(108)锁持有的S锁.读执行计划图1-3,写执行计划图1-4

(由于在默认隔离级别下(读提交)读申请S锁只是瞬间过程,读完立即释放,不会等待事务完成),所以在并发,执行频率不高的情形下不易出现.但我们模拟的高频情况使得S锁获得频率非常高,此时就出现了仅仅两个会话,一个读,一个写就造成了死锁现象.

图1-3

图1-4
死锁原因:读操作中的键查找造成的额外锁(聚集索引)需求

解决方案:在了解了死锁产生的原因后,解决起来就比较简单了.

我们可以从以下几个方面入手.

a 消除额外的键查找锁需的锁

b 读操作时取消获取锁

a.1我们可以创建覆盖索引使select语句中的查询列包含在指定索引中

CREATE NONCLUSTERED INDEX [inx_nlskey_incont2] ON [dbo].[testklup]
([nlskey] ASC) INCLUDE ( [cont2])

a.2 根据查询需求,分步执行,通过聚集索引获取查询列,避免键查找.

declare @cont2 char(3000)
declare @clskey int
while 1=1
begin
  select @clskey=clskey from testklup where nlskey=1

  select @cont2=cont2 from testklup where clskey=@clskey
end

b 通过改变隔离级别,使用乐观并发模式,读操作时源行无需锁

declare @cont2 char(3000)
while 1=1
begin
  select @cont2=cont2 from testklup with(nolock) where nlskey=1
end

结束语.我们在解决问题时,最好弄清问题的本质原因,通过问题点寻找出适合自己的环境的解决方案再实施.

赞 (0)

相关推荐

  • ASP.NET MVC4 Razor模板简易分页效果

    一.无数据提交 第一步,建立一个 Controller命名为PageIndex的空控制器,自定义一个方法如下: public ActionResult PageIndex(string action, string controller, int currentPage, int pageCount) { //int count = db.Product.Count(); ViewBag.PageCount = pageCount;//从操作中获取总数据页数将传入分页视图页面 ViewBag.C

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

    MySQL死锁问题是很多程序员在项目开发中常遇到的问题,现就MySQL死锁及解决方法详解如下: 1.MySQL常用存储引擎的锁机制 MyISAM和MEMORY采用表级锁(table-level locking) BDB采用页面锁(page-level locking)或表级锁,默认为页面锁 InnoDB支持行级锁(row-level locking)和表级锁,默认为行级锁 2.各种锁特点 表级锁:开销小,加锁快;不会出现死锁;锁定粒度大,发生锁冲突的概率最高,并发度最低 行级锁:开销大,加锁慢;

  • InnoDB数据库死锁问题处理

    场景描述 在update表的时候出现DeadlockLoserDataAccessException异常 (Deadlock found when trying to get lock; try restarting transaction...). 问题分析 这个异常并不会影响用户使用,因为数据库遇到死锁会自动回滚并重试.用户的感觉就是操作稍有卡顿.但是监控老是报异常,所以需要解决一下. 解决方法 在应用程序中update的地方使用try-catch. 我自己封装了一个函数,如下. /** *

  • 解决 .NET Core 中 GetHostAddressesAsync 引起的 EnyimMemcached 死锁问题

    在我们将站点从 ASP.NET + Windows 迁移至 ASP.NET Core + Linux 的过程中,目前遇到的最大障碍就是 -- 没有可用的支持 .NET Core 的 memcached 客户端. 我们一直用的是 EnyimMemcached ,在没有其它选择的情况下,我们自己尝试着将 EnyimMemcached 迁移至 .NET Core...基于 .NET Core 修改好了代码,在开发环境下测试通过,在 Linux 服务器上自己访问很正常(没有并发访问量),但是只要接入一定

  • ASP.NET MVC5+EF6+EasyUI后台管理系统 微信公众平台开发之消息管理

    ASP.NET MVC5+EF6+EasyUI后台管理系统 微信公众平台开发之消息管理

    前言 回顾上一节,我们熟悉的了解了消息的请求和响应,这一节我们来建立数据库的表,表的设计蛮复杂 你也可以按自己所分析的情形结构来建表 必须非常熟悉表的结果才能运用这张表,这表表的情形涵盖比较多 思维导图 我这个人比较喜欢用思维导图来分析和表达一些模型: 表结构  根据思维导图,我们可以建立的表可以是3张表:消息表,规则表,类型表 消息表:实际的消息 规则表:文本.图文.语音等 类型表:文本.图文.语音(默认回复,订阅回复) 也可以是两张表:规制表,消息表(+一个类型字段) 我这里只设计一张表:消

  • ASP.NET Core 数据保护（Data Protection）上篇

    ASP.NET Core 数据保护（Data Protection）上篇

    前言  上一篇记录了如何在 Kestrel 中使用 HTTPS(SSL), 也是我们目前项目中实际使用到的. 数据安全往往是开发人员很容易忽略的一个部分,包括我自己.近两年业内也出现了很多因为安全问题导致了很多严重事情发生,所以安全对我们开发人员很重要,我们要对我们的代码的安全负责. 在工作中,我们常常会见到 encode,base64,sha256, rsa, hash,encryption, md5 等,一些人对他们还傻傻分不清楚,也不知道什么时候使用他们,还有一些人认为MD5就是加密算法.

  • ASP.NET 程序员都非常有用的85个工具

    介绍 这篇文章列出了针对ASP.NET开发人员的有用工具. 工具 1.Visual Studio Visual Studio Productivity Power tool:Visual Studio专业版(及以上)的扩展,具有丰富的功能,如快速查找,导航解决方案,可搜索的附加参考对话框等 ReSharper:提高.NET开发人员生产力的工具,提高代码质量,通过提供快速修复消除错误,等等 MZ-Tools:它可以在方法.文件.项目.解决方案或项目组.选定的文本,文件组合或项目组合中找到字符串.结

  • ASP.NET MVC中URL地址传参的两种写法

    ASP.NET MVC中URL地址传参的两种写法

    一.url地址传参的第一种写法 1.通过mvc中默认的url地址书写格式:控制器/方法名/参数 2.实例:http://localhost:39270/RequestDemo/Index/88,默认参数名为id所以名称为id. 如果使用其他名称,后台是无法读取的会报错 二.url地址传参的第二种写法 1.使用?加参数名=参数值的写法,如果有多个参数使用&来连接 http://localhost:39270/RequestDemo/Index?id=88&name=%E5%BC%A0%E4%

  • sql server 2000阻塞和死锁问题的查看与解决方法

    数据库发生阻塞和死锁的现象: 一.数据库阻塞的现象:第一个连接占有资源没有释放,而第二个连接需要获取这个资源.如果第一个连接没有提交或者回滚,第二个连接会一直等待下去,直到第一个连接释放该资源为止.对于阻塞,数据库无法处理,所以对数据库操作要及时地提交或者回滚.二.数据库死锁的现象:第一个连接占有资源没有释放,准备获取第二个连接所占用的资源,而第二个连接占有资源没有释放,准备获取第一个连接所占用的资源.这种互相占有对方需要获取的资源的现象叫做死锁.对于死锁,数据库处理方法:牺牲一个连接,保证另外

  • 深入浅出解析mssql在高频,高并发访问时键查找死锁问题

    深入浅出解析mssql在高频,高并发访问时键查找死锁问题

    死锁对于DBA或是数据库开发人员而言并不陌生,它的引发多种多样,一般而言,数据库应用的开发者在设计时都会有一定的考量进而尽量避免死锁的产生.但有时因为一些特殊应用场景如高频查询,高并发查询下由于数据库设计的潜在问题,一些不易捕捉的死锁可能出现从而影响业务.这里为大家介绍由于设计问题引起的键查找死锁及相关的解决办法. 这里我们在测试的同时开启trace profiler跟踪死锁视图(locks:deadlock graph).(当然也可以开启跟踪标记,或者应用扩展事件(xevents)等捕捉死锁)

  • php 根据url自动生成缩略图并处理高并发问题

    服务器生成缩略图的时机一般分为两种: 1.上传文件时生成 优点:上传时就已经生成需要的缩略图,读取时不需要再判断,减少cpu运算. 缺点:当缩略图尺寸变化时或新增尺寸时,需要重新生成所有的缩略图. 2.访问时生成 优点:1.当有用户访问时才需要生成,没有访问的不用生成,节省空间. 2.当修改缩略图尺寸时,只需要修改设置,无需重新生成所有缩略图. 缺点:当缩略图不存在需要生成时,高并发访问会非常耗服务器资源. 虽然访问时生成会有高并发问题,但其他优点都比第一种方法好,因此只要解决高并发问题就可以.

  • 浅谈Nginx10m+高并发内核优化详解

    何为高并发 默认的Linux内核参数考虑的是最通用场景,不符合用于支持高并发访问的Web服务器,所以需要修改Linux内核参数,这样可以让Nginx拥有更高的性能: 在优化内核时,可以做的事情很多,不过,我们通常会根据业务特点来进行调整,当Nginx作为静态web内容服务器.反向代理或者提供压缩服务器的服务器时,期内核参数的调整都是不同的,这里针对最通用的.使Nginx支持更多并发请求的TCP网络参数做简单的配置: 这些需要修改/etc/sysctl.conf来更改内核参数. 配置方法 配置详析

  • Redis高并发问题的解决方法

    本文讲述了Redis高并发问题的解决办法.分享给大家供大家参考,具体如下: redis为什么会有高并发问题 redis的出身决定 redis是一种单线程机制的nosql数据库,基于key-value,数据可持久化落盘.由于单线程所以redis本身并没有锁的概念,多个客户端连接并不存在竞争关系,但是利用jedis等客户端对redis进行并发访问时会出现问题.发生连接超时.数据转换错误.阻塞.客户端关闭连接等问题,这些问题均是由于客户端连接混乱造成. 同时,单线程的天性决定,高并发对同一个键的操作会

  • 高并发nginx服务器的linux内核优化配置讲解

    由于默认的linux内核参数考虑的是最通用场景,这明显不符合用于支持高并发访问的Web服务器的定义,所以需要修改Linux内核参数,是的Nginx可以拥有更高的性能: 在优化内核时,可以做的事情很多,不过,我们通常会根据业务特点来进行调整,当Nginx作为静态web内容服务器.反向代理或者提供压缩服务器的服务器时,期内核参数的调整都是不同的,这里针对最通用的.使Nginx支持更多并发请求的TCP网络参数做简单的配置: 以下linux 系统内核优化配置均经在线业务系统测试,并发10万左右服务器运行

  • JPA使用乐观锁应对高并发方式

    目录 JPA使用乐观锁应对高并发 高并发系统的挑战 悲观锁的问题 乐观锁是个好东西 给数据库添加乐观锁 乐观锁 -业务判断 解决高并发 JPA使用乐观锁应对高并发 高并发系统的挑战 在部署分布式系统时,我们通常把多个微服务部署在内网集群中,再用API网关聚合起来对外提供.为了做负载均衡,通常会对每个微服务都启动多个运行实例,通过注册中心去调用. 那么问题来了,因为有多个实例运行都是同一个应用,虽然微服务网关会把每一个请求只转发给一个实例,但当面对高并发时,但它们仍然可能同时操作同一个数据库表,这

  • c#编写的高并发数据库控制访问代码

    代码的作用在于保证在上端缓存服务失效(一般来说概率比较低)时,形成倒瓶颈,从而能够保护数据库,数据库宕了,才是大问题(比如影响其他应用). 假设(非完全正确数据,仅做示例): 每秒支持10,000,000次查询(千万); 一次读库需要耗时:1ms; 修改内存变量需要耗时:0.001ms; 那么: 每秒最终访问的数据库的请求数量 < 1000 其他的9,900,000个请求会返回到其他页面.这就是为啥很多抢单网站有人可以访问,而有人得到繁忙中页面的原因. 微观到1ms来看,在currentVali

  • java高并发ThreadPoolExecutor类解析线程池执行流程

    java高并发ThreadPoolExecutor类解析线程池执行流程

    目录 摘要 核心逻辑概述 execute(Runnable)方法 addWorker(Runnable, boolean)方法 addWorkerFailed(Worker)方法 拒绝策略 摘要 ThreadPoolExecutor是Java线程池中最核心的类之一,它能够保证线程池按照正常的业务逻辑执行任务,并通过原子方式更新线程池每个阶段的状态. 今天,我们通过ThreadPoolExecutor类的源码深度解析线程池执行任务的核心流程,小伙伴们最好是打开IDEA,按照冰河说的步骤,调试下Th

  • Redis处理高并发机制原理及实例解析

    1.Redis是基于内存的,内存的读写速度非常快: 2.Redis是单线程的,省去了很多上下文切换线程的时间: 3.Redis使用多路复用技术,可以处理并发的连接.非阻塞IO 内部实现采用epoll,采用了epoll+自己实现的简单的事件框架.epoll中的读.写.关闭.连接都转化成了事件,然后利用epoll的多路复用特性,绝不在io上浪费一点时间. 下面重点介绍单线程设计和IO多路复用核心设计快的原因 为什么Redis是单线程的 1.官方答案 因为Redis是基于内存的操作,CPU不是Redi

  • 大数据量高并发的数据库优化详解

    如果不能设计一个合理的数据库模型,不仅会增加客户端和服务器段程序的编程和维护的难度,而且将会影响系统实际运行的性能.所以,在一个系统开始实施之前,完备的数据库模型的设计是必须的. 一.数据库结构的设计 在一个系统分析.设计阶段,因为数据量较小,负荷较低.我们往往只注意到功能的实现,而很难注意到性能的薄弱之处,等到系统投入实际运行一段时间后,才发现系统的性能在降低,这时再来考虑提高系统性能则要花费更多的人力物力,而整个系统也不可避免的形成了一个打补丁工程. 所以在考虑整个系统的流程的时候,我们必须

随机推荐