简单介绍SQL Server里的闩锁

在今天的文章里我想谈下SQL Server使用的更高级的，轻量级的同步对象：闩锁（Latch）。闩锁是SQL Server存储引擎使用轻量级同步对象，用来保护多线程访问内存内结构。文章的第1部份我会介绍SQL Server里为何需要闩锁，在第2部份我会给你介绍各个闩锁类型，还有你如何能对它们进行故障排除。

为何我们需要闩锁？
闩锁首次在SQL Server 7.0里引入，同时微软首次引入了行级别锁（row-level locking）。对行级别锁引入闩锁的概念是非常重要的，不然的话在内存中会出现丢失更新（Lost Updates）的现象。如我所说的，闩锁是存储引擎使用的轻量级同步对象，是SQL Server用来保护内存结构的。闩锁只不过是类似于多线程编程里的所谓的临界区（Critcal Section）概念。

在传统并发编程里，临界区是同时只能一个线程运行的代码。闩锁本身是个临界区的特殊版本，由于它允许多个并发读操作。在SQL Server的上下文里这意味着多个线程可以并发读取一个同享数据结构，例如内存中的页，但是写入同享数据结构一定要是单个线程进行。

闩锁是用来调和数据库里多个线程物理履行，但是锁是基于选择的事务隔离级别，用来逻辑取得需要的隔离级别。作为开发者或DBA的你，你可以用区别方式影响锁——例如通过SQL Server里的隔离级别，或通过各种可用锁提示。另外一方面闩锁是不能以直接方式控制的。在SQL Server里没有闩锁提示，也没有可用闩锁隔离级别。下表是锁和闩锁之间的比较：

　　　　　　　　         锁（Locks）　　　　　　　　　闩锁（Latches）

控制……　　　　　       　事务　　　　　　　　　　　　　　线程
保护……　　　　          数据库内容　　　　　　　　　　内存中数据结构
模式……　　　　         同享的（Shared），　　　　　　保持（Keep），
　　　　　　　　         更新（Update），　　　　　　   同享的（Shared），

　　　　　　　　         排它的（Exclusive），　　　　　更新（Update），排它的（Exclusive），

　　　　　　　　         意向的（Intension）　　　　　　烧毁（Destroy）

死锁……　          检测并解决（detection&resolution）　　通过严谨代码来避免
保持在……　　锁管理器的哈希表（Hashtable）　　 保护的数据结构（Protected Data Structure）
从表里可以看到，闩锁支持更细粒度保持（Keep）和烧毁（Destroy）模式。保持闩锁主要用来援用计数，例如当你想知道在指定闩锁上有多少其它闩锁在等待。烧毁闩锁是最有限制的一个（它乃至会阻塞保持闩锁），当闩锁被烧毁时会用到，例如当惰性写入器（Lazy Writer）想要释放内存中的页时。我们先介绍下各种闩锁模式，然后说下各个闩锁模式的兼容性。

NL（空闩锁）：

                   内部
                   未使用

KP（保持闩锁）：

                   可以由多个任务同时持有
                   只被一个DT模式的闩锁阻塞

SH（同享闩锁）：

                  读取数据页的时候使用
                   可以由多个任务同事持有
                  阻塞EX模式和DT模式的闩锁

UP（更新闩锁）：

                  写入系统分配页面和tempdb的行版本化页面时使用
                 一个这类模式的闩锁只能被一个单独的任务持有

EX（排它闩锁）：

                   写入数据页的时候使用
                   一个这类模式的闩锁只能被一个单独的任务持有

DT（烧毁闩锁）：

                  很少使用
                  一个这类模式的闩锁只能被一个单独的任务持有

在SQL Server里，一致性不能只用锁来取得。SQL Server或者可以访问没被锁管理器保护的同享数据结构，例如页头。还有SQL Server基于闩锁基础的其他组件也是，有单线程代码路径。好了，我们继续讲授SQL Server里的各种闩锁类型，还有如何对它们进行故障排除。

闩锁类型与故障排除
SQL Server辨别3个区别闩锁种别

                   IO闩锁
                 缓冲区闩锁（BUF）
                 非缓冲区闩锁（Non-BUF）

我们来详细看下这3个区别种别。当在缓冲池的页读写操作未完成——即当你读自/写入你的存储子系统时（2者未同步），SQL Server会使用IO闩锁（I/O Latches）。对这些I/O闩锁，SQL Server在统计信息里以PAGEIOLATCH_为前缀出现。你可以在DMV sys.dm_os_wait_stats 查看下这些闩锁类型的等待。

使用这些闩锁，SQL Server保证那些页不会并发屡次读入缓存池，那些页也不会从缓存池疏忽，在那些页需要被查询访问的时候。

除这些I/O闩锁外，SQL Server也支持所谓的缓存区闩锁（Buffer Latches），它用来保护缓冲池里页不会被并发运行的线程影响。这些闩锁，SQL Server使用它们来禁止内存中的丢失更新（Lost Updates）。没有这类闩锁，在缓存池里会有并发的读写页，它们会引发主内存里页的破坏。对这些缓存闩锁，SQL Server在统计信息里以PAGELATCH_为前缀出现。你可以在DMV sys.dm_os_wait_stats 查看下这些闩锁类型的等待。这里最重要的是你触及了主内存的竞争，由于他们的等待类型名称里不包括IO字样。

最后SQL Server内部使用所谓的非缓存区闩锁（Non-Buffer Latches）来保护除缓冲池外的同享数据结构。对这些非缓存闩锁，SQL Server在统计信息里以LATCH_为前缀出现。你可以在DMV sys.dm_os_wait_stats 查看下这些闩锁类型的等待。

但在这个DMV里这些对非缓存区闩锁的等待只是SQL Server内部使用的各个闩锁的概况信息，你可以在单独的DMV sys.dm_os_latch_stats找到更详细的信息。

SQL Server 2014内部使用163个闩锁来同步同享数据结构的访问。其中一个著名的闩锁是FGCB_ADD_REMOVE，它用来保护文件组的文件组控制阻塞（ File Group Control Block （FGCB）），在以下特定操作期间：

        文件增长（手动或自动）
       增加/删除文件组文件
       重新计算填充比重（Recalculating proportional fill weightings）
       在循环分配期间，通过文件组的文件回收。
当你看到这个闩锁排在前列是，你肯定有太多自动增长操作的问题，缘由是你数据库糟的默许配置。当查询尝试读/写保护的数据结构且需要等待一个闩锁时，查询就会进入挂起状态，直到闩锁可以成功获得。因此查询经过的全部查询生命周期包括运行（RUNNING），挂起（SUSPENDED），可运行（RUNNABLE），最后再次运行（RUNNING）。因此，当查询长时间把持闩锁时，强迫同享数据结构保护才成心义。那是由于改变查询状态也意味着进行Windows系统里的上下文切换，根据引入的CPU周期是个很昂贵的操作。

因此对读写频繁或极短时间内的同享数据结构上放上闩锁没成心义。在这个情况下，需要的上下文切换会杀死SQL Server的整体性能，它需要花费太多的时间来完成全部查询生命周期（运行（RUNNING），挂起（SUSPENDED），可运行（RUNNABLE））。那就是是SQL Server引入的所谓自旋锁(Spinlocks)。锁管理器就是这样数据结构的好例子：当锁定或解锁数据对象（例如记录，页等）时只需要单个线程访问。但当你查看sys.dm_os_latch_stats时，你会发现没有闩锁保护锁管理器本身。锁管理器使用的哈希表里对应的哈希桶使用自旋锁来保护——LOCK_HASH自旋锁。通过锁管理器履行锁定和解锁操作前，一定要取得自旋锁。

本篇文章到此结束，如果您有相关技术方面疑问可以联系我们技术人员远程解决，感谢大家支持本站！