我最近参与调试一个棘手的 SQL Server 锁定问题。我们最终通过研究应用程序代码弄清楚了发生了什么，但如果 SQL Server 提供更多信息会容易得多。我想知道是否有办法获取这些信息。这是一个简单的复制：
create table Table1 (k int primary key)
create table Table2 (k int primary key)
go
begin transaction
insert into Table1 values (1) -- acquire a lock
go
insert into Table2 values (2) -- acquire a second lock
go
我没有显示它，但应用程序正在提交事务，因为它应该有。但是，在提交发生之前，它会导致阻塞，并且我们的调试工具只报告最后执行的批处理/语句的文本——在这种情况下插入到 Table2 中——以及对应于完全不同对象的锁。（我的示例中的表 1。）
有没有办法获取与会话持有的所有锁相对应的 SQL，而不仅仅是最近的一批？
我记得有一次读到，在编译查询时，可以强制 SQL Server 假定表具有一定的大小，或者甚至可能覆盖统计直方图。如果可能的话，有人可以解释如何做到这一点吗？
需要明确的是：这样做的目的是在编写查询时在生产之外进行假设情景分析。 我不是在谈论修改查询本身或使用查询提示。 （修改查询和使用查询提示的示例可以在这个问题的答案中找到。）
我试图更好地理解 SQL Server 的执行引擎在低内存状态下的行为方式。就内存授予而言，我想知道是否有某种方法可以强制GrantedMemory等于RequiredMemory. （我的猜测是有一个未记录的跟踪标志可以做到这一点。有人知道它是什么吗？）
扩展事件的 SSMS GUI 允许您按类别（“错误”、“执行”等）和通道（“分析”、“操作”等）过滤事件。如何以编程方式获取事件的类别和频道映射？
我正在尝试通过 T-SQL 获取有关现有的、已停止的扩展事件会话的配置信息。如果会话开始，那么sys.dm_xe_session_object_columnsDMV 就会准确地给出我正在寻找的内容。该信息在某处可用于已停止的会话吗？
我正在查看 TechNet 上列出的 SQL Server 物理运算符（不要判断，你知道你已经完成了），并读到 Hash Match 物理运算符有时用于实现UNION逻辑运算符。
我从未见过这样做，并想了解更多。一个示例查询会很棒。什么时候使用它，什么时候比替代品更好？（这些通常是相同的，但并非总是如此。）
我正在尝试使用 SentryOne Plan Explorer 工具（版本 3.0，内部版本 11.0.84.0）和 SQL Server Microsoft SQL Server 2014 (SP2-CU3) 调整查询。Plan Explorer 报告的每个表的读取次数与查询报告的总数之间的读取次数不一致。报告的总数比每个表读取的总和大一个数量级，并且比原始查询大得多。
很抱歉我无法发布屏幕截图。我在高度安全的行业工作，我无法访问图片托管网站。
这是我正在运行的查询：
SELECT sd.*, ss.*
FROM dbo.SecurityActivityRange AS ar
JOIN dbo.SecurityDaily AS sd ON sd.accountId = ar.accountId
AND sd.securityId = ar.securityId
AND sd.reportDate = 5000
AND sd.isHeld = 1
JOIN dbo.SecuritySemiStatic AS ss ON ss.accountId = sd.accountId
AND ss.securityId = sd.securityId
AND ss.semiStaticDate = sd.semiStaticDate
WHERE ar.accountId = 1
AND ar.startDate <= 5000
AND ar.endDate >= 5000
我将从 SSMS 复制每个表的数字，因为它已经是文本并且包含与 Plan Explorer 报告的信息相同的信息：
Table 'SecurityActivityRange'. Scan count 0, logical reads 92, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'SecuritySemiStatic'. Scan count 0, logical reads 194, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'SecurityDaily'. Scan count 1, logical reads 6, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
这是来自 Plan Explorer，在“结果”选项卡中，在“声明”下：
Statement Est Cost Duration CPU Est CPU Cost Reads Writes Est IO Cost Est Rows End Time Actual Rows Start Time
SELECT ... 100.0% 33 47 100.0% 3,590 78 100.0% 1 2017-... 46 2017-02...
您可以看到总读取数为 3590，比 292 大得多。我也很想知道为什么它会报告写入。
这是执行计划的文本版本：
|--Nested Loops(Inner Join, OUTER REFERENCES:([ss].[securityId]))
|--Nested Loops(Inner Join, OUTER REFERENCES:([sd].[securityId], [sd].[semiStaticDate], [Expr1005]) WITH UNORDERED PREFETCH)
| |--Clustered Index Seek(OBJECT:([sws_db].[dbo].[SecurityDaily].[PK_SecurityDaily] AS [sd]), SEEK:([PtnId1001]=(100) AND [sd].[accountId]=(1) AND [sd].[reportDate]=(5000)), WHERE:([sws_db].[dbo].[SecurityDaily].[isHeld] as [sd].[isHeld]=(1)) ORDERED FORWARD)
| |--Clustered Index Seek(OBJECT:([sws_db].[dbo].[SecuritySemiStatic].[PK_SecuritySemiStatic] AS [ss]), SEEK:([PtnId1003]=RangePartitionNew([sws_db].[dbo].[SecurityDaily].[semiStaticDate] as [sd].[semiStaticDate],(1),(1097),(1462),(1828),(1918),(2009),(2101),(2193),(2224),(2252),(2283),(2313),(2344),(2374),(2405),(2436),(2466),(2497),(2527),(2558),(2589),(2617),(2648),(2678),(2709),(2739),(2770),(2801),(2831),(2862),(2892),(2923),(2954),(2983),(3014),(3044),(3075),(3105),(3136),(3167),(3197),(3228),(3258),(3289),(3320),(3348),(3379),(3409),(3440),(3470),(3501),(3532),(3562),(3593),(3623),(3654),(3685),(3713),(3744),(3774),(3805),(3835),(3866),(3897),(3927),(3958),(3988),(4019),(4050),(4078),(4109),(4139),(4170),(4200),(4231),(4262),(4292),(4323),(4353),(4384),(4415),(4444),(4475),(4505),(4536),(4566),(4597),(4628),(4658),(4689),(4719),(4750),(4781),(4809),(4840),(4870),(4901),(4931),(4962),(4993),(5023),(5054),(5084),(5115),(5146),(5174),(5205),(5235),(5266),(5296),(5388),(5480),(5570),(5661),(5753),(5845),(5936),(6027),(6119),(6211),(6301),(6392),(6484),(6576),(6666),(6757),(6849),(6941),(7031),(7122),(7214),(7306),(7397),(7488),(7580),(7672),(7762),(7853),(7945),(8037),(8127),(8218),(8310),(8402),(8492),(8583),(8675),(8767),(8858),(8949),(9041),(9133),(9223),(9314),(9406),(9498),(9588),(9679),(9771),(9863),(9953),(10044),(10136),(10228),(10319),(10410),(10502),(10594),(10684),(10775),(10867),(10959),(11049),(11140),(11232),(11324),(11414),(11505),(11597),(11689),(11780),(11871),(11963),(12055),(12145),(12236),(12328),(12420),(12510),(12601),(12693),(12785),(12875),(12966),(13058),(13150),(13241),(13332),(13424),(13516),(13606),(13697),(13789),(13881),(13971),(14062),(14154),(14246),(14336),(14427),(14519),(14611),(14702),(14793),(14885)) AND [ss].[accountId]=(1) AND [ss].[semiStaticDate]=[sws_db].[dbo].[SecurityDaily].[semiStaticDate] as [sd].[semiStaticDate] AND [ss].[securityId]=[sws_db].[dbo].[SecurityDaily].[securityId] as [sd].[securityId]) ORDERED FORWARD)
|--Clustered Index Seek(OBJECT:([sws_db].[dbo].[SecurityActivityRange].[PK_SecurityActivityRange] AS [ar]), SEEK:([ar].[accountId]=(1) AND [ar].[securityId]=[sws_db].[dbo].[SecuritySemiStatic].[securityId] as [ss].[securityId]), WHERE:([sws_db].[dbo].[SecurityActivityRange].[startDate] as [ar].[startDate]<=(5000) AND [sws_db].[dbo].[SecurityActivityRange].[endDate] as [ar].[endDate]>=(5000)) ORDERED FORWARD)
您可以看到它没有使用任何可能溢出到磁盘的运算符。
我已经对查询进行了试验，似乎两个连接都是看到这种行为所必需的。我还发现ss.*从列子句中删除也会使差异消失。
在阅读了大量有关 SQL Server 中临时表和表变量之间差异的文章后，我正在尝试从主要使用临时表切换到主要使用表变量。（它们似乎更适合我通常使用的查询类型。）
在这些查询中，表包含驱动查找过程的唯一标识符。我的习惯是，在使用临时表时，包含一个PRIMARY KEY约束，以便查询优化器知道它不会看到任何重复项。PRIMARY KEY但是，鉴于优化器（在大多数情况下，对于我的查询）假定表变量仅包含一行*，根据定义这是唯一的，如果存在约束，查询优化器是否会做出不同的选择？
* 从技术上讲，它假设没有行，但是用一个替换了零。（因为零与估计过程的其余部分交互非常差。）但这也取决于在编译查询时是否填充表变量。这里有一些背景信息：What's the difference between a temp table and table variable in SQL Server? .
我目前正在使用 SQL Server 2014，但如果新版本的行为发生变化，我会很好奇。
正如已经指出的那样，PRIMARY KEY聚集索引附带了一个约束，它为查询优化器提供了更多关于如何从表变量中获取数据的选择。我知道这一点并考虑了查询计划的其余部分。但是在试图澄清我的问题之后，我认为我试图提出的问题过于宽泛，而且可能特别针对我的极端情况。（除了对 5000 亿行表的导航类型查询，期望亚秒级性能。）所以我将按原样保留我的问题。