一、问题描述
此种现象实则少见，一旦遇见，如没有处理经验足以令一个身经百战sql server DBA怀疑人生，从业18年sql server数据库以来，第二次遇见，和第一次遇到一样瞬间被打入懵逼状态
遇到的问题，进程大量阻塞，大量的僵尸进程，影响就是整个数据库处于hang死状态，客户端请求大量超时，干脆就请求不进来，数据库服务器cpu并不高，在30%左右。
1）kill进程，解决不了，正所谓kill我一个，会有千千万万个我马上冲进来
2）重启数据库服务器，解决不了，重启完了，进程马上阻塞
3）优化sql，解决不了，大量被阻塞的都是主键key-value的update单条语句，insert单条语句，甚至是阻塞源
4）只能程序端一个模块一个模块的服务器停止，直到某个模块停止服务，阻塞解开
第一次遇见此问题是2年前，也就是2018年3,4月份，当时数据库处于hang死状态，hang死一段时间后，always on 的1主8从的某些从库会跟主库断开同步。针对此种问题束手无策，DBA经理决定跟微软开了case，case部署一套监控，监控出来的数据都是16进制，看着像编译语言，文件反馈给微软分析。微软一个女工程师反馈，反馈的是针对一个自动增长表内存资源争用问题，需要程序调整解决。数据库在程序解决前要做的是做了一个监控循环脚本，当监控进程的一个参数到某一个临界值，就kill进程（只可惜后来赌气离职走人，笔记本也被我撒气摔坏了，此监控脚本在我这里已石沉大海），kill进程有点粗鲁，甚至有点残暴，但总比整个数据库hang死要好很多。那段好几天电话跟那个微软女工程师沟通交流，声音比较甜美，起码四个+号，本来就对微软工程师有崇敬之感，又一女工程，崇敬感加倍！不过，转面一想，能挑起微软工程师职位，想必是李莫愁，灭绝师太级的人物吧，嘿嘿
二、问题源头
此种问题不是通常慢查询，加加索引，优化一下sq就能搞定的。因为慢查询是慢，但他自己在玩，并不影响别人。这个问题的现象不是，一些简单的key-value的单条主键update或者单条insert语句被阻塞，甚至成为阻塞源。此刻，一个叫做“闩锁”的名词该闪亮登场了。
闩锁是SQL Server存储引擎使用轻量级同步对象，用来保护多线程访问内存内结构。
对于行级别锁引入闩锁的概念是非常重要的，不然的话在内存中会出现丢失更新（Lost Updates）的现象。如我所说的，闩锁是存储引擎使用的轻量级同步对象，是SQL Server用来保护内存结构的。闩锁只不过是类似于多线程编程里的所谓的临界区（Critcal Section）概念。
在传统并发编程里，临界区是同时只能一个线程运行的代码。闩锁本身是个临界区的特殊版本，因为它允许多个并发读操作。
闩锁是用来协调数据库里多个线程物理执行，然而锁是基于选择的事务隔离级别，用来逻辑获得需要的隔离级别。作为开发者或DBA的你，你可以用不同方式影响锁——例如通过SQL Server里的隔离级别，或者通过各种可用锁提示。
然而闩锁是不能以直接方式控制的。在SQL Server里没有闩锁提示，也没有可用闩锁隔离级别。下表是锁和闩锁之间的比较：
锁（Locks）闩锁（Latches）
三、闩锁处理
面对闩锁，DBA束手无策，处理需要开发重改架构代码，大家都知道一个大数据量的系统，有太多事务就已经很dei儿，要是事务里面还有很多线程，或者引起闩锁的自动增长内存资源抢占问题，更是dei儿上加dei儿！
数据库hang死，如果进程里wait_type会有大量的PAGELATCH出现，这时候就考虑一下闩锁问题，先一个模块一个模块的试，定位到相应引起闩锁的模块，此模块如有有自动增长或者多线程，如果还有事务就大事务化小事务，小事务化无，多线程不适合用oltp里面，尽量减少或者干脆就消除，多线程可以用在olap里面。对于自动增长的这种，目前我还没想到该如何处理，设计上尽量让操作同一自增长表不同sql尽量不在小事务上相互交叉，别相互在内存争资源。
四、结束语
对技术无论何时何地都该怀有敬畏之心。不能装逼，虽说装逼装的好容易当领导，但在技术领域上永远在路上。
