SQL Server内存中OLTP高并发实战：从锁等待到性能优化

做DBA这么多年，被SQL Server的锁等待、闩锁竞争、磁盘IO瓶颈磨到没脾气的日子，我估计每个运维老手都有一肚子苦水。某次给一个订单系统做优化，高峰期并发一上来，sys.dm_os_waiting_tasks里密密麻麻全是LCK_M_X和PAGEIOLATCH_SH，CPU倒是不高，就是堵得死死的。当时我盯着一堆死锁图看了半天，最终把目光落在了SQL Server 2014就引入的那项功能上——内存中OLTP（Hekaton）。

这东西不是新玩意了，但国内生产环境真正敢把核心业务表迁进去的其实不多。我踩过坑、也吃到过甜头，这篇笔记就把内存中OLTP从原理到实战的完整链路捋一遍。适合正在做SQL Server高并发改造的DBA、被锁阻塞折磨的运维同学，以及准备把关键业务表往内存优化表上迁移的架构师。我会尽量用实际场景说话，把该避的坑全部标记出来。

1. 为什么需要Hekaton：传统表在高并发下的瓶颈在哪

在说内存中OLTP怎么用之前，必须先搞清楚它到底解决的是什么样的痛。很多人以为SQL Server慢就是“服务器不行”或者“索引不对”，但真到了每秒几万次小事务写入的场景，问题根本不是单条SQL能跑多快，而是整个并发体系扛不扛得住。

1.1 磁盘IO、锁和闩锁三重夹击

传统行存储表（B-Tree堆或聚集索引表）里，一条数据要落到磁盘的某个页上。写入的时候，数据页要么从内存缓存池里拿，要么从磁盘读进来，只要目标页不在缓存里，这条写入就必须等一次物理IO。哪怕你用SSD，一次随机写也有几十微秒的延迟，这个延迟在高并发下会被放大，不是线性放大，是指数级放大——因为大家都在等同一个资源，等的人越多，队列越长。

比IO更头疼的是锁。SQL Server默认用悲观并发，更新一行就要拿X锁，X锁会和所有其他锁不兼容。两个会话要更新同一行，后到的人只能停在LCK_M_X等待里。锁等待堆积到一定量，就是阻塞链，再严重就是死锁，系统直接扔一个1205出来。很多业务系统遇到这种场景，第一反应是加索引，优化SQL，但锁竞争本身和SQL写得好不好关系不大，只要并发达到一定程度，哪怕单条语句跑5毫秒，100个并发一起执行，总耗时也是灾难级的。

还有一个很多人忽略的是闩锁（Latch），它比锁更底层。数据页在内存里被修改时，SQL Server用闩锁保护页结构的物理一致性。页分裂、页切换、缓存池走查这些操作都需要短暂持有页闩锁，这玩意本来应该只有几微秒，可一旦某个页被反复访问，Latch竞争立刻就会浮出来。传统表高并发下出现PAGEIOLATCH_EX或者PAGE_LATCH_EX等待类型时，加索引解决不了，索引本身也依赖页结构，换成Hekaton的表反而可以彻底绕过这个机制。

1.2 为什么传统优化手段在写密集场景下会失效

我给系统做过很多轮优化，最明显的感受是，读密集场景用索引覆盖、用读写分离、用查询提示，效果立竿见影。但写密集场景不一样，索引越多，写入时维护索引的成本越大。你在一个表上建了5个索引，每个INSERT都要维护5棵B-Tree，这意味着5次页闩锁操作、5次可能的页分裂。为了读得快而建的索引，在写多读少的场景里反而是拖累。

再者，SQL Server的事务日志记录对写入性能影响极大。每条INSERT/UPDATE都会写日志，日志行要同步落盘（取决于提交模式），这个日志IO开销很难通过加索引优化掉。反过来看内存中OLTP，它设计之初就把“写日志”和“更新内存结构”分开处理，专门为短小精悍的高频事务做了优化，这也是Hekaton能大幅提升写性能的核心原因之一。

所以，Hekaton的核心价值可以一句话概括：把表放到内存里，用无锁数据结构和高并发友好的事务机制，消灭锁等待和闩锁竞争，同时减少日志记录对写路径的阻塞。它不是为了跑大查询设计的，而是为了高并发、小事务、持续写入这样一类典型OLTP负载设计的。

2. 内存中OLTP的底层运作机制：MVCC、原生编译与新型索引

Hekaton这个代号听起来像个希腊地名，其实是SQL Server 2014里的一个内部项目代号。后来正式名字改叫In-Memory OLTP。很多人第一次听到“内存中OLTP”，第一反应是“这不就是内存表吗”。这么说对了一半，但要理解它为什么能比传统内存中的缓存页表现好那么多，必须盯着三个底层设计看：行版本控制（MVCC）、原生编译、以及专为内存设计的索引结构。

2.1 行版本控制：读写互不阻塞是怎么做到的

内存优化表默认采用乐观并发的多版本并发控制机制。传统表也会用行版本控制，但那是配合读提交快照隔离（RCSI）用的，版本记录放在tempdb里，有额外的IO和清理成本。而内存中OLTP的行版本机制完全在内存中实现，每一行数据本身就是一个多版本结构，包含行的开始时间、结束时间、创建事务ID、删除事务ID等信息。

当一个更新事务发生时，新版本直接写入内存，旧版本在原位置标记为“已被替换”。正在进行读取的会话，通过事务ID判断自己能看到哪个版本，完全不需要等待写事务释放锁。写事务之间依然需要检测冲突，但读写之间彻底解耦了。这意味着，在某个高频更新表上，读操作再也不需要排队等写操作完成，写操作也不需要照顾读操作。这个机制的效果在真实系统中非常直观：我在压测中做一个不断INSERT和不断SELECT的混合场景，传统表的LCK_M_S等待几乎清不掉，内存优化表同配置下等待类型列表基本可以清空。

2.2 原生编译：从解释执行到机器码

Hekaton的另一大杀器是原生编译（Natively Compiled）。普通T-SQL存储过程每次执行都要经过解析、绑定、优化、生成执行计划的过程，SQL Server虽然做了计划缓存，但缓存查找、解释执行、运行时检查仍然有开销。而原生编译的存储过程在创建时就被编译成DLL（机器码），执行过程中直接调用编译产物，不再做解释和计划生成。

把存储过程编译成机器码，这事听起来很神奇，但实际用下来，提升最明显的不是单条语句的CPU时间，而是反复执行同样逻辑时的稳定低延迟。你少了很多运行时分支判断、少了上下文切换，这种差距在高频小事务下会形成数量级的差异。不过注意，原生编译有非常多的限制，比如不能用动态SQL、不能游标、不能调用部分系统函数。所以实际项目里，往往不是把所有过程都改成原生编译，而是选最热的那一两条路径单独做。

有人会问，既然原生编译快，为什么不让所有存储过程都原生编译？因为原生编译的存储过程只能访问内存优化表（和部分内存优化表变量），并且约束很死，分布式逻辑、复杂的JSON解析这类操作基本都做不了。所以它的定位很明确：为短小的高频事务而生。

2.3 哈希索引与非聚集索引：B-Tree之外的新选择

内存中OLTP支持两类索引。一类是哈希索引（Hash Index），这是最出名的。它内部是一个哈希桶数组，等值查找（WHERE id = xxx）只要算一次哈希，再扫一遍该桶的链，复杂度近似O(1)。相比传统B-Tree查找需要的树遍历，在数百万行甚至千万级行的表上，哈希索引的点查优势非常明显。

但是哈希索引有一个非常容易踩的坑——它不维护有序性，你的查询如果是范围查询，比如WHERE create_time BETWEEN ... AND ...，哈希索引帮不上忙，SQL Server会退化成全表扫描。而且哈希索引建立在创建表时指定的BUCKET_COUNT上，桶数量要与预期的唯一键数量匹配。桶太少，哈希冲突多，每个桶后面的链表变长，性能退化；桶太多，内存白浪费，一条数据一个桶，内存开销翻好几倍。

另一类是非聚集索引（Range Index），底层是类似B-Tree的内存结构，支持范围查找和排序，但它的写路径没有传统页的页分裂问题。实际建表时，一般建议把主键设为非聚集索引用于范围查询，另建哈希索引用于热点等值查询；两者可以共存。注意，内存优化表的索引不能像传统表那样轻易加，改动索引结构往往需要重建表，所以一开始的设计必须想清楚。

3. 哪些业务场景真正值得迁移：评估管线和边界条件

Hekaton再好，也不是所有表都适合迁移。刚开始接触内存优化表的人最容易犯的错误是“把所有大表都迁进去”，结果内存吃紧、功能受限、改造量巨大，最后草草回滚。我自己的经验是，先想清楚一个表的负载特征，再决定要不要碰它。

3.1 适合内存中OLTP的三类业务形态

我把适合场景总结成三类。

第一类是高频点查+高频更新的小表，典型如会话表、在线状态表、库存余量表、计数器表。这类表行数通常不高，几万到几十万行，但每秒访问次数极高，且以等值查询为主，几乎不做大范围扫描。传统模式下这类表是锁等待的重灾区，迁到内存优化表后收益最直观。

第二类是突发流量下的写并发潮。比如秒杀或大促场景里的扣减库存、抢券记录。平时流量低没法暴露问题，一到活动时间，全部请求涌向同一张表，传统表直接锁死。Hekaton的MVCC机制在写冲突可控（同一行同时更新的概率不高）的场景下表现极佳。

第三类是缓冲型数据表。比如业务系统里的操作流水、异步消息表，Append-only写入模式，读取往往按最近时间分页拉取。用SCHEMA_ONLY非持久化的内存优化表做中间缓冲区，数据重要性不高但写入频率极高，非常合适。

3.2 不适合的场景：别拿Hekaton硬扛大查询

有一类场景我明确不建议迁移：需要大数据量聚合分析的报表表。内存优化表的并行扫描能力虽然从2016年开始有了，但整体相比传统行存储聚合并无优势，更何况它更吃内存。如果你有一个100GB的事实表，每周做一次GROUP BY汇总，把它搬到内存优化表只会让你为了容量去购买大量内存，性能提升却微乎其微。

另外，频繁变更表结构的场景也不适合。说实话，内存优化表对ALTER TABLE的支持一直都很弱。虽然SQL Server 2016之后放开了一部分操作，比如添加/删除索引仍需重建表，修改列类型也是重建。你在开发阶段天天改表结构，绝对会被这玩意折磨疯。

还有一点，需要跨表JOIN且查询模式很动态的表，尽量别迁。内存优化表和传统表的跨表JOIN可以做，但内存优化表和原生编译存储过程的JOIN只能发生在内存优化表之间，原生编译过程不能访问传统表。如果你的核心过程要同时操作两类表，那改造量就会大很多。

3.3 内存成本和持久化级别的选择

内存优化表必须驻留在内存里，这个“内存”可不是你想的缓存页池，而是SQL Server给Hekaton单独管理的一部分内存。它不像Buffer Pool那样可以按压力回收。所以规划时必须预留足够的内存配额。官方文档的指导值是：内存优化表占用的内存通常是数据实际大小的一到两倍，因为行版本、索引结构、哈希桶都会额外占用空间。假设你的表数据一共10GB，你至少要给SQL Server预留20GB以上的内存余量，只多不少。

持久化方面，内存优化表分两种。DURABILITY = SCHEMA_AND_DATA是持久化表，数据会记录到事务日志，并且通过定期Checkpoint落盘，数据库重启后能恢复；DURABILITY = SCHEMA_ONLY是非持久化表，表结构保留，但数据在重启后全部消失，写入它不需要同步日志落盘，性能比持久化表还快一大截。选择哪种取决于业务对数据丢失的容忍度，比如会话表丢了大不了让用户重新登录，用SCHEMA_ONLY完全合理；但订单表你敢用SCHEMA_ONLY试试，老板马上找你谈话。

4. 从零开始部署内存中OLTP：建库、建表、改存储过程的完整链路

纸上谈兵聊了一堆原理，现在给出可以直接照着做的部署步骤。我会把整个流程拆成四段：环境检查、数据库配置、建表、改造存储过程。每一步我都会标出容易翻车的地方。

4.1 环境检查：版本、内存和事务隔离级别

不满足条件的话，后面所有步骤都是白搭。

• SQL Server版本：内存中OLTP是SQL Server 2014引入的企业版功能。2016开始扩展了更多支持。Express版和Standard版虽然新版支持，但内存优化表受内存大小限制（Standard版有内存限制）。生产建议企业版。
• 内存：目标表数据量 + 索引结构 + 行版本 + 哈希桶，估算后至少留25%的内存余量给系统和其他负载。如果服务器内存紧张，先别谈什么性能，连创建都会失败。
• 数据库兼容级别：建议把数据库兼容级别设为130（SQL Server 2016）或更高，很多限制在低兼容级别下依然生效。

检查一下：

sql复制SELECT SERVERPROPERTY('Edition'), SERVERPROPERTY('ProductVersion'), SERVERPROPERTY('IsXTPSupported');

如果IsXTPSupported返回0，说明当前版本不支持。这一步5秒钟，能筛掉一半准备踩坑的人。

4.2 给数据库添加内存优化文件组

数据库必须有一个专门的MEMORY_OPTIMIZED_DATA文件组，用来存放内存优化表的Checkpoint文件。这步很多人会忘掉，因为普通建库的默认实例不会包含这种文件组。

sql复制ALTER DATABASE [YourDatabase]
ADD FILEGROUP [InMemoryDATA] CONTAINS MEMORY_OPTIMIZED_DATA;
GO

ALTER DATABASE [YourDatabase]
ADD FILE
(
    NAME = N'InMemoryDATA_File1',
    FILENAME = N'D:\SQLServerData\YourDatabase_InMemoryDATA.ndf'
)
TO FILEGROUP [InMemoryDATA];
GO

注意文件路径必须是一个目录，SQL Server会在里面生成很多子目录和文件（Checkpoint文件对），你别指着它只有一个文件。另外这个文件组不支持自动增长，如果磁盘满了，内存优化表会开始报错。建议把路径放到高性能的本地SSD上，别放网络存储。

4.3 创建内存优化表：语法、DURABILITY和索引设计

建表语法跟普通表很接近，核心差别是加了MEMORY_OPTIMIZED = ON和DURABILITY = ...。下面这个例子，我建一个会话Token表，考虑热点等值查询，主键用范围索引，另外加一个哈希索引专门服务WHERE Token = @token这类型查询。

sql复制CREATE TABLE dbo.UserSession
(
    SessionId        INT NOT NULL IDENTITY(1,1) PRIMARY KEY NONCLUSTERED,
    UserId           INT NOT NULL,
    Token            UNIQUEIDENTIFIER NOT NULL,
    LoginTime        DATETIME2 NOT NULL,
    LastActiveTime   DATETIME2 NOT NULL,
    IsActive         BIT NOT NULL,
    INDEX idx_TokenHash HASH (Token) WITH (BUCKET_COUNT = 1000000)
)
WITH (MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_ONLY);
GO

细节解释一下：

• 主键是PRIMARY KEY NONCLUSTERED，内存优化表里不支持聚集索引概念，所有索引都是非聚集的。
• idx_TokenHash HASH (Token) WITH (BUCKET_COUNT = 1000000)创建哈希索引，BUCKET_COUNT建议按预期Token数量估算，一般设为预期行数的1.5到2倍。这个表预期几十万在线用户，桶设为100万比较合理。如果设得太小，哈希冲突链会变长；设得太大，内存浪费。实际压测时可以查DMV看链长度再调整。
• DURABILITY = SCHEMA_ONLY表示会话表可以容忍重启丢失，换来最高写入性能。订单、资金类表别这么干，用SCHEMA_AND_DATA。

这里有个设计上的坑：哈希索引不能作为主键索引之外覆盖排序的索引。如果你的查询需要按LoginTime排序分页，哈希索引没法支持，必须靠主键的范围索引或者额外再加一个非聚集索引。想清楚你的查询模式再设计索引，后面改起来成本很高。

4.4 改造存储过程：原生编译与解释执行的差异

普通存储过程可以直接访问内存优化表，不强制改成原生编译。但要想获得最大收益，要写原生编译的存储过程。语法上标记NATIVE_COMPILATION，下面是一个实际例子：

sql复制CREATE PROCEDURE dbo.usp_UpdateLastActive
    @SessionId INT,
    @LastActiveTime DATETIME2
WITH NATIVE_COMPILATION, SCHEMABINDING
AS
BEGIN ATOMIC WITH
(
    TRANSACTION ISOLATION LEVEL = SNAPSHOT,
    LANGUAGE = N'us_english'
)
    UPDATE dbo.UserSession
    SET LastActiveTime = @LastActiveTime
    WHERE SessionId = @SessionId;
END;
GO

两个关键点：

第一，BEGIN ATOMIC块是原生编译过程的事务边界。传统存储过程靠BEGIN TRAN管理事务，原生编译过程没有这个，整个块本身就是一个原子事务。

第二，TRANSACTION ISOLATION LEVEL = SNAPSHOT这里不是让你决定就可以随便写的。内存优化表原生编译过程中支持的最高隔离级别就是快照隔离，底层靠MVCC实现。如果你在这块逻辑里还要访问普通磁盘表，快照隔离可能会引发非常大的开销和迁移难度。我建议原生编译过程只处理内存优化表，跨表的复杂业务放到外面普通过程中调。

4.5 保存已有数据：从磁盘表迁移到内存优化表的三种方式

如果你有一个现成的普通表要迁到内存优化表，常用做法有三种。

方式一：用SSMS的“内存优化表向导”。对着表右键“设计”可以走一遍可视化流程，自动生成脚本，检查兼容性。适合表不多、结构简单的场景。

方式二：用数据导出导入。先在目标库里建好内存优化表，然后INSERT INTO ... SELECT ... FROM ...。注意，这一步如果是大表，跑全表插入会生成大量事务日志，内存优化表也一样要写日志（持久化表），建议分批提交。

方式三：用bcp或者SSIS。适合大数据量迁移，边导边校验。迁移完务必对比行数、校验关键字段汇总值。

不管用哪种方式，迁移前的兼容性检查是必须的。微软提供了sys.sp_xtp_check_required_columns之类的辅助函数，另外在SSMS向导里做一次“Validate”可以快速识别不兼容的数据类型。比如XML、TEXT、NTEXT、IMAGE在内存优化表里都是不支持的，有这些类型的表需要先改结构。

5. 上线之后看什么：性能监控、常见故障与调优心得

部署只是开始，真正考验人的是监控和调优。内存优化表出问题时，报错信息往往不像传统表那么直观，你得学会看一组专属视图。自己踩过的几个坑，我挨个说。

5.1 内存用量和三组关键DMV

内存是内存优化表的命，监控内存是第一优先级。

sql复制-- 表级内存消耗
SELECT OBJECT_NAME(object_id) AS tbl,
       memory_allocated_for_table_kb / 1024 AS allocated_mb,
       memory_allocated_for_indexes_kb / 1024 AS index_mb
FROM sys.dm_db_xtp_table_memory_stats;

-- 哈希索引的分布和链长度
SELECT OBJECT_NAME(object_id) AS tbl,
       index_id,
       total_bucket_count,
       empty_bucket_count,
       avg_chain_length,
       max_chain_length
FROM sys.dm_db_xtp_hash_index_stats;

avg_chain_length如果超过5，说明哈希索引的桶数量明显偏低了，需要扩容。max_chain_length很高表示某些热点值冲突严重，这种情况无论怎么扩桶都救不了“同一行被疯狂并发更新”的问题，得从业务上拆分热点行。

另外，sys.dm_db_xtp_transactions能看当前内存优化表事务状态，如果长时间处于等待状态，说明有长事务卡住了，要立刻排查。

5.2 三大高频错误：013、701和41305

我整理了一个高频报错表，全部是自己压测和线上遇到过或者同事踩过的。

先讲41305。很多人做内存优化表的高并发INSERT测试时撞到这个错误，第一反应是操作为什么比普通表还不稳定。原因在于内存优化表的并发控制是基于验证的，事务提交时会检查版本冲突，冲突了直接报错，而不是靠锁等在那里。这种机制叫乐观并发，并发高且同热点行争抢严重时，报错概率会直线上升。解决办法不是改数据库配置，而是让业务层做轻量重试，或者降低同一行的并发更新频次。

再说701/802。SQL Server给Hekaton分配的内存是有上限的，默认情况下它和Buffer Pool争抢同一个服务器内存池。如果没有给它预留资源池，当Buffer Pool把内存占满时，内存优化表再申请内存就会失败。绑定资源池是官网推荐做法：

sql复制-- 创建资源池，并绑定
CREATE RESOURCE POOL [InMemoryPool] WITH (MAX_MEMORY_PERCENT = 30);
ALTER RESOURCE GOVERNOR RECONFIGURE;
EXEC sp_xtp_bind_db_resource_pool N'YourDatabase', N'InMemoryPool';
ALTER RESOURCE GOVERNOR RECONFIGURE;

这段代码给内存优化表列了一个30%的内存上限，避免它和其他工作负载互相抢内存。绑定之后，还得在数据库里执行一次ALTER DATABASE ... SET MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT = ON，否则多个数据库共同运行时资源池不生效。这步很细节，我见过有人绑了池还是内存不足，改完这个设置就好了。

5.3 表结构调整的代价：ALTER TABLE修改为何要重建

我前面反复强调表结构设计要谨慎，这里用一个真实案例说下为什么。某次版本迭代，我们要给内存优化表加一个索引，执行ALTER TABLE dbo.OrderCache ADD INDEX idx_OrderTime ...。结果等了很久，期间表上的打点查询偶尔超时，因为SQL Server在后台重建整张表的数据结构，并且需要额外内存。

内存优化表有个特性：对表定义做任何结构性变更，实际上都是重新创建一个新版本的表，然后把数据复制过去。这意味着：

• 表越大，重建时间越长。
• 重建期间，表的数据副本要占额外内存。
• 如果内存不够，变更直接失败，表还是原来的样子。
• 大表重建时，在线业务可能受影响。

后来我跟团队定的规矩是：内存优化表的索引、约束、列定义在开发初期就必须冻结，上线后绝不轻易动。如果确实要改，先搭建影子表，用时间段相对空闲的时候做切换，别在业务高峰期直接ALTER。

5.4 持久化表的Checkpoint与恢复行为

持久化内存优化表（SCHEMA_AND_DATA）通过Checkpoint文件和事务日志来保证持久性。SQL Server会周期性地把内存中的数据写入Checkpoint文件，一旦数据库重启，内存优化表从Checkpoint文件恢复，再通过日志补齐增量部分。这个恢复过程最怕的是Checkpoint文件本身出了问题，比如磁盘坏道、文件组空间不够，恢复就会卡住。

另外一个容易被忽略的点是，数据库备份必须包含内存优化表文件组，否则你只备份了PRIMARY文件组，恢复出来内存优化表是空的。用SSMS做完整备份默认会包含所有文件组，但如果你用自定义脚本只备份个别文件组，务必检查。备份出来后，最好在测试环境做一次恢复演练，确认数据真的在。

5.5 从2014到2022：这十年Hekaton发生了哪些变化

最后聊点版本差异。早期Hekaton（2014）确实门槛高、限制多，劝退了不少人。比如2014里不支持外键约束、不支持并行查询、原生编译过程支持的函数非常有限，很多表迁过去要改一堆配套代码。到了2016，情况明显改善：支持范围索引、支持并行扫描、ALTER TABLE的部分操作放开、数据类型支持扩展。2017进一步提升了内存优化表的临时表和表变量场景。2019开始，SQL Server把智能查询处理能力延伸到了内存优化表上，查询计划更聪明了。2022更是把TempDB的系统表升级成了内存优化表，间接提升了整体的并发稳定性。

所以我的建议是：如果你用的是SQL Server 2014/2016的老项目，想上Hekaton，先仔细评估版本限制；如果已经用2019/2022，内存中OLTP的成熟度和稳定性已经完全值得认真考虑。

写到这里，我回头想了一下，第一批吃螃蟹的人骂Hekaton难用，其实骂得没错，当年确实一堆限制。但数据库技术就是这样的，一个新特性出来，第一版往往只适合少数先锋用户，等版本迭代个两三次，才轮到我们这些普通DBA摘果子。内存中OLTP不是说把表丢内存里就自动快，它的正确打开方式是：选对表、设计好索引、控制好事务边界、监控好内存，然后把它用在真正高并发的小事务写路径上。做到这几点，你会在峰值压测里看到一个几乎空白的等待类型列表，那感觉相当值回票价。