SQL Server死锁根因：VARCHAR(MAX)与INCLUDE索引的锁冲突

简介本资源是一份深入剖析SQL Server死锁机制的技术文档面向数据库管理员、后端开发工程师及SQL性能优化从业者聚焦一个典型却易被忽视的非对称死锁场景——由non-clustered索引中INCLUDE大字段varchar(max)引发的更新冲突。文档完整复现问题在含聚簇索引与两个带INCLUDE(d)的非聚簇索引表上并发执行相同WHERE条件的ROWLOCK更新时稳定触发死锁并通过三组对照实验移除INCLUDE、缩小字段长度至varchar(200)验证根因结合1222跟踪标志与SQL Profiler锁事件捕获详解死锁图解读与sp_readerrorlog日志分析方法。资源为1个694KB的docx文件内容涵盖建表脚本、复现步骤、Trace配置要点、死锁XML关键字段标注及规避建议结构清晰、实操性强。目前已有327人学习下载适合希望掌握SQL Server底层锁行为、提升生产环境死锁诊断能力的中高级DBA与开发人员。1. 为什么两条一模一样的 UPDATE 会互相卡死——一个被 varchar(max) INCLUDE 拖进死锁黑匣子的真实案例你有没有试过写一条看似人畜无害的UPDATE ... WHERE a value在 SQL Server 上跑着跑着就突然报错“Transaction (Process ID XX) was deadlocked on lock resources with another process and has been chosen as the deadlock victim.”更诡异的是把索引里一个INCLUDE(d)去掉或者只把d varchar(max)改成varchar(200)死锁就消失了——代码没动、逻辑没变、数据量没增、并发数没加就改了两个配置项结果从“必现死锁”变成“稳如泰山”。这不是玄学是 SQL Server 在底层执行计划与锁资源调度之间打出的一记组合拳。本文要讲的就是一个真实复现、可验证、可推演的死锁案例它不依赖外部应用层并发控制不靠事务隔离级别调高调低纯粹由表结构设计clustered index two non-clustered indexes INCLUDE varchar(max)和 SQL Server 查询优化器行为共同触发。适合正在做数据库课设、毕设中涉及高并发更新模块的同学也适合刚接手遗留系统、发现“明明单条 UPDATE 很快但一上生产就频繁死锁”的工程师——你不是写错了 SQL而是没看清 SQL Server 在背后悄悄做了什么。2. 死锁复现三步建表、两轮对比、一次稳定触发要真正理解这个死锁第一步不是看执行计划而是亲手把它“打出来”。只有能稳定复现的问题才配谈分析只有能精准控制变量的问题才值得深挖。本节提供一套零依赖、纯 T-SQL 的复现脚本并明确标注每一步的设计意图和关键参数确保你在 SQL Server 2008 R2 及以上版本含 2012/2014/2016/2019均可 100% 复现。注意所有操作请在独立测试库如DeadlockDemo中执行避免影响生产环境。2.1 表结构设计三个索引的“精密陷阱”我们创建一张名为tt的测试表其结构刻意模拟了常见业务场景中的“宽索引”设计主键为idclustered业务查询字段a和b各建一个非聚集索引并通过INCLUDE(d)把大字段d“塞进”索引页意图实现覆盖查询Covering Index。但正是这个“好意”埋下了死锁伏笔。-- 创建测试库如未存在 CREATE DATABASE DeadlockDemo; GO USE DeadlockDemo; GO -- 创建表id为主键clustereda/b为业务查询字段d为大文本字段 CREATE TABLE tt ( id INT IDENTITY PRIMARY KEY, a CHAR(36), b CHAR(36), d VARCHAR(MAX) ); GO -- 创建两个 non-clustered index均 INCLUDE(d) -- ⚠️ 关键点INCLUDE(d) 使索引页实际存储 d 字段值而非仅指针 CREATE INDEX ix_a_bc ON tt(a) INCLUDE(d); CREATE INDEX ix_b_cd ON tt(b) INCLUDE(d); GO设计说明VARCHAR(MAX)类型在 SQL Server 中属于 LOBLarge Object数据类型其存储机制与普通VARCHAR(n)截然不同。当d被INCLUDE进索引时SQL Server 必须将整个 LOB 值或其指针内联部分物理存入索引 B-Tree 页中。这直接导致索引页变大、分裂更频繁、更新路径更复杂——而这些正是后续死锁链路的物理基础。2.2 数据填充与定位让 UPDATE 有“靶子”可打插入 10,000 条记录并非为了压力测试而是为了确保索引统计信息足够“真实”让查询优化器不会因数据量过少而选择全表扫描等非常规路径。同时我们固定取第 10 行的a值作为更新目标保证两次并发 UPDATE 操作绝对作用于同一行物理记录排除“不同行竞争”干扰。-- 插入 10000 条测试数据使用 NEWID() 确保 a 值唯一且随机 INSERT INTO tt (a, b, d) SELECT NEWID(), bbb, ddd GO 10000 -- 查询第 10 行的 a 值用于后续 UPDATE 定位 SELECT id, a FROM tt WHERE id 10; -- 假设返回 a EF211985-EA72-4A40-81DA-0AAB076E7AA3每次运行值不同提示此处a值必须手动复制因为NEWID()是非确定性函数无法在后续 UPDATE 中用子查询动态获取否则会破坏“单行更新”前提。这是复现可控性的关键细节。2.3 并发触发双连接循环 UPDATE死锁立现打开两个独立的 SSMS 查询窗口即两个 SPID分别执行以下脚本。注意不要点击“执行”后等待而是两个窗口几乎同时1 秒内点击执行。你会在 1~3 秒内看到其中一个窗口报出死锁错误。-- 【窗口 1】SPID A例如 SPID54 WHILE 1 1 BEGIN UPDATE tt WITH(ROWLOCK) SET d cd WHERE a EF211985-EA72-4A40-81DA-0AAB076E7AA3; -- 可选添加短暂停顿便于观察但非必需 -- WAITFOR DELAY 00:00:00.01; END-- 【窗口 2】SPID B例如 SPID60 WHILE 1 1 BEGIN UPDATE tt WITH(ROWLOCK) SET d cd WHERE a EF211985-EA72-4A40-81DA-0AAB076E7AA3; -- WAITFOR DELAY 00:00:00.01; END现象确认几秒后其中一个窗口会中断并显示Msg 1205, Level 13, State 42, Line X Transaction (Process ID 54) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.这证明死锁已稳定触发。此时你已拥有了一个可调试、可分析的“活体标本”。2.4 对比实验三组对照直指死锁根因死锁不是故障是信号。它告诉你当前的表结构与访问模式存在资源争用路径。我们设计三组对照实验每组只改变一个变量观察死锁是否消失。这不仅是验证更是逆向工程的起点。实验编号修改动作预期结果验证命令执行前需先清理Test 1基准保持原表结构ix_a_bcix_b_cd均INCLUDE(d)d VARCHAR(MAX)✅ 必现死锁DROP TABLE IF EXISTS tt;重新执行 2.1~2.3Test 2去 INCLUDE删除两个索引的INCLUDE(d)仅保留ON(a)/ON(b)❌ 死锁消失DROP INDEX ix_a_bc ON tt; DROP INDEX ix_b_cd ON tt; CREATE INDEX ix_a_bc ON tt(a); CREATE INDEX ix_b_cd ON tt(b);Test 3改类型保持INCLUDE(d)但ALTER COLUMN d VARCHAR(200)❌ 死锁消失ALTER TABLE tt ALTER COLUMN d VARCHAR(200);然后重建索引关键洞察Test 2 和 Test 3 的成功排除了“死锁源于并发 UPDATE 本身”的误判。它强有力地指向一个结论死锁的开关不在应用逻辑而在索引的物理组织方式与数据类型的存储特性耦合上。下一步就是用工具撬开 SQL Server 的黑匣子看它到底在锁什么、按什么顺序锁。3. 死锁诊断从 1222 输出到 SQL Trace 锁序列还原完整争用链复现只是开始诊断才是核心。SQL Server 提供了两套互补的死锁捕获机制轻量级的DBCC TRACEON(1222, -1)输出文本日志和重量级的 SQL Server Profiler图形化事件流。本节将带你用这两套工具像法医一样解剖死锁现场精确到毫秒级的锁申请/释放顺序并最终绘制出那张决定性的“锁资源等待图”。3.1 开启全局死锁捕获1222 跟踪标志DBCC TRACEON(1222, -1)是最快速、最低开销的死锁捕获方式。它将每次死锁的详细 XML 结构写入 SQL Server 错误日志Error Log无需额外工具。执行一次即可长期生效重启服务后失效生产环境建议用启动参数-T1222持久化。-- 启用全局 1222 跟踪需 sysadmin 权限 DBCC TRACEON(1222, -1); GO -- 验证是否启用返回 1 表示已启用 DBCC TRACESTATUS(1222, -1); GO注意-1参数表示全局启用所有会话区别于仅对当前会话启用的DBCC TRACEON(1222)。生产环境慎用但测试环境完全安全。3.2 获取死锁日志sp_readerrorlog 解析 XML 片段死锁发生后立即执行sp_readerrorlog读取最新错误日志。由于日志可能滚动我们指定读取第 0 个文件当前活动日志并搜索关键词deadlock-list定位最近一次死锁记录。-- 读取当前错误日志查找最近的死锁记录 EXEC sp_readerrorlog 0, 1, deadlock-list; GO输出是一大段 XML其中最关键的deadlock-list节点包含两个process死锁双方和resource-list争用资源。我们聚焦提取以下信息Victim Process:deadlock victimprocess5e27708—— 被选为牺牲者的进程 ID。SPID:process ... spid60 ...—— 对应 SSMS 窗口的会话 ID。Wait Resource:process ... waitresourceKEY: 8:72057594066108416 (ef8a9edf5a1e) ...—— 等待的锁资源标识格式KEY: dbid:hobtid(hash)。Lock Mode:process ... lockModeX ...—— 当前持有的锁模式UUpdate, XExclusive。Execution Stack:executionStackframe ...—— 执行的 SQL 语句已参数化。设计说明waitresource中的hobtidHeap or B-tree ID是核心线索。它唯一标识一个索引或堆的物理分区。我们需要将其映射回具体的索引名才能知道“它在等哪个索引上的锁”。3.3 hobtid 映射索引sys.partitions sys.indexes 关联查询hobtid是一个 64 位整数不能直接阅读。我们通过sys.partitions视图将其关联到sys.indexes从而获得可读的索引名。-- 将 hobtid 转换为索引名替换为你从 1222 日志中看到的实际 hobtid 值 SELECT t.name AS table_name, i.name AS index_name, i.type_desc AS index_type, p.partition_id AS hobtid, p.rows AS row_count FROM sys.partitions p INNER JOIN sys.indexes i ON p.object_id i.object_id AND p.index_id i.index_id INNER JOIN sys.tables t ON i.object_id t.object_id WHERE p.partition_id IN ( 72057594066108416, -- 示例 hobtid1来自 1222 日志 72057594065518592 -- 示例 hobtid2来自 1222 日志 );典型输出table_name | index_name | index_type | hobtid | row_count -----------|---------------------------|----------------|------------------|---------- tt | ix_a_bc | NONCLUSTERED | 72057594066108416| 10000 tt | PK__tt__3213E83F10E07F16 | CLUSTERED | 72057594065518592| 10000这证实了死锁发生在ix_a_bc非聚集索引和主键聚集索引PK__tt__...之间。3.4 SQL Trace 深度追踪锁定 SPID捕获完整锁生命周期1222 日志告诉我们“谁等谁”但不知道“怎么等来的”。要还原锁的申请与释放顺序必须用 SQL Server Profiler或更现代的 Extended Events。本节以 Profiler 为例SQL Server 2019 及以后推荐用 XE但 Profiler 更直观易懂。操作步骤打开 SQL Server Profiler → 新建 Trace → 连接到你的测试实例。在 “Events Selection” 页勾选Locks→Lock:Acquired,Lock:Released,Deadlock GraphTSQL→SQL:BatchStarting,SQL:BatchCompleted点击 “Column Filters” → 在SPID列设置过滤器输入你已知的两个 SPID如54和60。点击 “Run”然后立即在两个 SSMS 窗口中执行 2.3 的 UPDATE 循环。死锁发生后停止 Trace保存.trc文件。关键分析点在 Profiler 结果中按StartTime排序筛选Lock:Acquired和Lock:Released事件重点关注Mode锁模式、ObjectID2即 hobtid、TextData锁对象描述。血泪经验Profier 默认不显示ObjectID2列。你必须右键列标题 → “Choose Columns…” → 勾选ObjectID2。否则你将无法将事件与具体索引关联这是新手最常踩的坑之一。3.5 绘制锁序列图从文字日志到可视化争用路径综合 1222 日志和 Profiler 数据我们可以绘制出死锁发生的精确时间线。下表是基于真实测试数据整理的锁序列简化版省略无关事件时间戳SPID事件类型锁资源hobtid锁模式索引名阶段T054Lock:Acquired72057594066108416Uix_a_bc查找阶段通过a值定位行T154Lock:Acquired72057594065518592UPK...更新阶段准备修改聚集键行T254Lock:Acquired72057594065518592XPK...执行更新修改d字段值T354Lock:Released72057594066108416Uix_a_bc释放查找锁T460Lock:Acquired72057594066108416Uix_a_bc查找阶段同样通过a值定位T560Lock:Acquired72057594065518592UPK...更新阶段准备修改T660Lock:Acquired72057594066108416Xix_a_bc阻塞需要升级为 X 锁以更新d但 SPID54 已释放 U 锁该页正被 SPID60 持有 U 锁不SPID54 已释放SPID60 却卡在申请 X 锁上等等……玄学时刻揭晓T3 后SPID54 释放了ix_a_bc的 U 锁但并未立即释放PK...的 X 锁。而 SPID60 在 T4 拿到ix_a_bc的 U 锁后在 T5 拿到PK...的 U 锁接着它需要ix_a_bc的 X 锁来更新d字段因为d在INCLUDE中但它自己正持有ix_a_bc的 U 锁无法升级U→X 需要等待自身释放 U 锁不SQL Server 允许 U→X 升级但此处有更深层原因。真正的瓶颈在于SPID54 在 T2 拿到PK...的 X 锁后还需要更新ix_b_cd索引因为d也在其INCLUDE中所以它接下来会申请ix_b_cd的 X 锁而 SPID60 在 T5 拿到PK...的 U 锁后也需要更新ix_a_bc和ix_b_cd于是双方在PK...和ix_a_bc之间形成了经典的“循环等待”。Profiler 的完整日志会清晰显示ix_b_cd的锁事件印证这一链条。4. 执行计划解密为什么一个 INCLUDE 让 SQL Server 多走三步死锁的表象是锁冲突根源是执行计划。SQL Server 不会凭空多申请锁它的一切锁行为都严格遵循执行计划中定义的数据访问路径。本节通过SET STATISTICS PROFILE ON获取实际执行计划非预估逐行解读三个关键实验的计划差异彻底搞清INCLUDE(d)与VARCHAR(MAX)如何联手“诱导”SQL Server 走上多步更新的歧途。4.1 获取实际执行计划STATISTICS PROFILE vs. GUI 执行计划SET STATISTICS PROFILE ON输出的是文本格式的实际执行计划Actual Execution Plan它包含每一行操作符的Rows实际处理行数、Executes执行次数等运行时统计比 SSMS 图形界面中点击“显示估计的执行计划”CtrlL更真实可靠尤其对于死锁这种依赖运行时状态的问题。-- 在执行 UPDATE 前开启 SET STATISTICS PROFILE ON; GO -- 执行你的 UPDATE务必用实际值非参数化 UPDATE tt WITH(ROWLOCK) SET d cd WHERE a EF211985-EA72-4A40-81DA-0AAB076E7AA3; GO SET STATISTICS PROFILE OFF; GO注意WITH(ROWLOCK)提示在此处不影响执行计划选择它只影响锁粒度但为保持与复现环境一致我们保留它。4.2 Test 1 执行计划三步走三把锁死锁温床这是基准实验d VARCHAR(MAX),INCLUDE(d)的执行计划核心片段已精简仅保留关键操作符Rows Executes StmtText ---- -------- ------------------------------------------------------------ 1 1 |--Clustered Index Update(OBJECT:([DeadlockDemo].[dbo].[tt].[PK__tt__3213E83F10E07F16]), SET:([d] [1])) 1 1 |--Top(ROWCOUNT est 0) 1 1 |--Index Seek(OBJECT:([DeadlockDemo].[dbo].[tt].[ix_a_bc]), SEEK:([a] [2]) ORDERED FORWARD) 1 1 |--Index Update(OBJECT:([DeadlockDemo].[dbo].[tt].[ix_a_bc]), SET:([d] [1])) 1 1 |--Compute Scalar(DEFINE:([Expr1003][1])) 1 1 |--Top(ROWCOUNT est 0) 1 1 |--Index Seek(OBJECT:([DeadlockDemo].[dbo].[tt].[ix_a_bc]), SEEK:([a] [2]) ORDERED FORWARD) 1 1 |--Index Update(OBJECT:([DeadlockDemo].[dbo].[tt].[ix_b_cd]), SET:([d] [1])) 1 1 |--Compute Scalar(DEFINE:([Expr1004][1])) 1 1 |--Top(ROWCOUNT est 0) 1 1 |--Index Seek(OBJECT:([DeadlockDemo].[dbo].[tt].[ix_a_bc]), SEEK:([a] [2]) ORDERED FORWARD)关键解读|--Clustered Index Update: 第一步更新聚集索引主键行修改d字段。|--Index Update(OBJECT:...[ix_a_bc]): 第二步更新ix_a_bc索引因为d在其INCLUDE中必须同步刷新。|--Index Update(OBJECT:...[ix_b_cd]): 第三步更新ix_b_cd索引同理。为什么是三步因为d是VARCHAR(MAX)其值无法完全内联存储在索引页中。SQL Server 必须将d的 LOB 数据或其指针单独维护并在任何包含它的索引更新时进行物理层面的同步写入。这导致了三个独立的Index Update操作符每个操作符在执行时都会申请并持有对应的 X 锁从而形成多点锁依赖。4.3 Test 2 执行计划一步到位一把锁死锁消失这是移除INCLUDE(d)后的执行计划Rows Executes StmtText ---- -------- ------------------------------------------------------------ 1 1 |--Clustered Index Update(OBJECT:([DeadlockDemo].[dbo].[tt].[PK__tt__3213E83F10E07F16]), SET:([d] [1])) 1 1 |--Top(ROWCOUNT est 0) 1 1 |--Index Seek(OBJECT:([DeadlockDemo].[dbo].[tt].[ix_a_bc]), SEEK:([a] [2]) ORDERED FORWARD)关键解读只有一个Clustered Index Update。Index Seek仍使用ix_a_bc快速定位但因为d不在INCLUDE中SQL Server 不需要更新该索引。更新只发生在聚集索引上锁只在PK...上申请和释放路径单一无循环等待可能。4.4 Test 3 执行计划一步三索引一把锁死锁消失这是d VARCHAR(200)但保留INCLUDE(d)的执行计划Rows Executes StmtText ---- -------- ------------------------------------------------------------ 1 1 |--Clustered Index Update(OBJECT:([DeadlockDemo].[dbo].[tt].[PK__tt__3213E83F10E07F16]), OBJECT:([DeadlockDemo].[dbo].[tt].[ix_a_bc]), OBJECT:([DeadlockDemo].[dbo].[tt].[ix_b_cd]), SET:([d] [1])) 1 1 |--Top(ROWCOUNT est 0) 1 1 |--Index Seek(OBJECT:([DeadlockDemo].[dbo].[tt].[ix_a_bc]), SEEK:([a] [2]) ORDERED FORWARD)关键解读Clustered Index Update操作符的OBJECT:后面列出了三个对象PK...,ix_a_bc,ix_b_cd。这意味着 SQL Server 选择了一个“批量更新”策略它一次性定位到行然后在一个原子操作中同步更新所有受影响的索引。为什么能批量因为VARCHAR(200)是固定长度或短变长数据可以完全内联存储在索引页中。SQL Server 的优化器判断一次性更新所有索引页比分步申请锁更高效因此生成了这个“单操作符、多对象”的计划。锁的申请/释放也集中在这一个操作符内生命周期短无中间状态自然规避了死锁。4.5 执行计划对比总结锁的数量与顺序由计划决定实验d类型INCLUDE执行计划特征Index Update操作符数量锁申请路径死锁风险Test 1VARCHAR(MAX)✅三个独立Index Update3ix_a_bc(U)→PK(X)→ix_a_bc(X)→ix_b_cd(X)⚠️ 高循环等待Test 2VARCHAR(MAX)❌一个Clustered Index Update1PK(U)→PK(X)✅ 无Test 3VARCHAR(200)✅一个Clustered Index Update多 OBJECT1PK(U)→PK(X)同步更新所有索引✅ 无核心结论重申死锁不是 SQL Server 的 Bug而是其查询优化器在特定数据类型与索引设计组合下做出的“看似合理”的执行计划选择。我们的任务不是抱怨优化器而是读懂它并用索引设计、数据类型、查询提示Query Hints等手段引导它走向更优路径。5. 避坑指南五个高频翻车点每一个都曾让我加班到凌晨死锁分析最耗时的环节往往不是技术本身而是被一些看似无关紧要的细节绊倒。以下是我在多个项目中包括某高校数据库课设答辩现场、某公司核心订单系统上线前压测亲历、验证过的五个高频翻车点。它们不炫技但每一个都足以让你在 deadline 前两小时抓狂。这里不讲原理只给“现象→原因→解决”的急救包。5.1 翻车点 1Profiler 没抓到死锁事件日志里也找不到 1222 记录现象按教程开启了DBCC TRACEON(1222, -1)也跑了 Profiler但死锁发生后sp_readerrorlog返回空Profiler 里也没有Deadlock Graph事件。原因SQL Server 服务账户没有写入错误日志目录的权限或错误日志文件已满/被归档。DBCC TRACEON成功但日志写入失败导致 1222 信息丢失。Profiler 未勾选Deadlock Graph事件它在 “Errors and Warnings” 分类下非 “Locks”。解决检查 SQL Server 服务账户如NT Service\MSSQLSERVER对MSSQL\Log目录的“写入”权限。在 SSMS 中右键实例 → “属性” → “数据库设置” → 确认“错误日志路径”正确且磁盘空间充足。Profiler 中务必在 “Events Selection” 页展开 “Errors and Warnings”勾选Deadlock Graph。5.2 翻车点 2hobtid 查不到索引名sys.partitions返回空现象从 1222 日志复制hobtid如72057594066108416执行SELECT ... FROM sys.partitions WHERE partition_id ...结果集为空。原因hobtid是partition_id但sys.partitions视图默认只返回当前数据库的对象。如果你在master或其他库中执行查询而死锁发生在DeadlockDemo库则查不到。另外hobtid可能对应一个已删除但未清理的临时索引极罕见。解决必须在发生死锁的数据库上下文中执行查询USE DeadlockDemo; GO SELECT ... FROM sys.partitions ...使用更鲁棒的查询关联sys.objects和sys.indexesSELECT o.name AS table_name, i.name AS index_name, i.type_desc FROM sys.partitions p JOIN sys.indexes i ON p.object_id i.object_id AND p.index_id i.index_id JOIN sys.objects o ON i.object_id o.object_id WHERE p.partition_id 72057594066108416 AND o.type U; -- 只查用户表5.3 翻车点 3Profiler 里看到一堆Lock:Acquired但分不清哪个是“查找锁”哪个是“更新锁”现象Profiler 输出数百行Lock:AcquiredMode列全是U或XObjectID2也都是数字无法对应到具体索引更别说区分“查找”和“更新”阶段。原因Lock:Acquired事件默认不显示Resource Type如 KEY, PAGE, OBJECT和Resource Description如(ef8a9edf5a1e)这种哈希值。没有这些Mode和ObjectID2就是天书。解决在 Profiler 的 “Events Selection” 页右键列标题 → “Choose Columns…” → 勾选以下关键列Resource Type显示KEY,PAGE,OBJECTResource Description显示(hash)可用于与 1222 日志比对Mode已存在但确保可见ObjectID2已存在但确保可见提示Resource Type KEY表示行级锁Resource Description的 hash 值与 1222 日志中的waitresource后缀一致是跨工具关联的唯一钥匙。5.4 翻车点 4SET STATISTICS PROFILE ON输出的执行计划里Rows列全是 0 或 1看不出“三步”痕迹现象执行UPDATE后STATISTICS PROFILE输出中Rows列大部分是0或1StmtText里也只看到Clustered Index Update没看到Index Update。原因你执行的是UPDATE语句但STATISTICS PROFILE捕获的是该语句的“实际执行计划”而UPDATE语句本身是一个原子操作。Index Update操作符是执行计划的内部节点STATISTICS PROFILE会完整输出但如果你的 SSMS 设置了“结果以网格显示”可能会截断长文本。解决在 SSMS 中执行SET STATISTICS PROFILE ON后务必在“结果”窗口中右键 → “将结果另存为…” → 保存为.txt文件然后用记事本打开。网格视图会自动换行导致StmtText被切碎。在.txt文件中用CtrlF搜索Index Update即可看到完整的三行或一行取决于实验。5.5 翻车点 5解决了死锁但 UPDATE 性能暴跌 10 倍现象听从建议把d VARCHAR(MAX)改成了VARCHAR(200)死锁消失但原来 10ms 的 UPDATE现在要 100ms。原因VARCHAR(200)虽然避免了 LOB 锁问题但INCLUDE(d)导致ix_a_bc索引页急剧膨胀每行多存 200 字节索引深度增加Index Seek的 IO 次数上升。或者d字段实际内容远超 200 字符导致TRUNCATE或 ERROR本文还有配套的精品资源点击获取