我有一个查询，它既容易受到参数敏感性的影响，又受表值参数的影响。我很懒，只想用查询提示来解决这个问题。当我懒惰的时候，我可以用 来解决参数敏感性问题OPTION (OPTIMIZE FOR UNKNOWN)。这给了我三个非常紧密相关的问题：
OPTION (OPTIMIZE FOR UNKNOWN)有影响吗？OPTION (OPTIMIZE FOR UNKNOWN)有影响吗？OPTION(RECOMPILE)可用于影响表值参数的基数估计？我自己的实验和文档都表明，这根本没用。表值参数很容易被参数嗅探，但嗅探到的只是基数，所以OPTION (OPTIMIZE FOR UNKNOWN)应该什么也不做。
至于使用其他表提示的问题，我知道我可以更改对表值参数的操作的估计（例如OPTION (USE HINT ('ASSUME_MIN_SELECTIVITY_FOR_FILTER_ESTIMATES')），但我不认为提示可以影响参数本身的基数估计。
这篇经典的并发安全文章显然是为一次只更新一行而设计的。在我的例子中，我有一个表值输入，并且希望以并发安全的方式更新每一行。我知道这并不总是可行的，但我希望尽可能地接近这一点。MERGE这似乎是一个自然的解决方案，但我并不信任它，而且它确实很容易出现 bug。Michael J. Swart 文章中剩下的两种方法是：
CREATE PROCEDURE s_AccountDetails_Upsert ( @Email nvarchar(4000), @Etc nvarchar(max) )
AS
SET XACT_ABORT ON;
BEGIN TRAN
UPDATE TOP (1) dbo.AccountDetails WITH (UPDLOCK, SERIALIZABLE)
SET Etc = @Etc
WHERE Email = @Email;
IF (@@ROWCOUNT = 0)
BEGIN
INSERT dbo.AccountDetails ( Email, Etc )
VALUES ( @Email, @Etc );
END
COMMIT
CREATE PROCEDURE s_AccountDetails_Upsert ( @Email nvarchar(4000), @Etc nvarchar(max) )
AS
SET XACT_ABORT ON;
BEGIN TRAN
INSERT dbo.AccountDetails ( Email, Etc )
SELECT @Email, @Etc
WHERE NOT EXISTS (
SELECT *
FROM dbo.AccountDetails WITH (UPDLOCK, SERIALIZABLE)
WHERE Email = @Email
)
IF (@@ROWCOUNT = 0)
BEGIN
UPDATE TOP (1) dbo.AccountDetails
SET Etc = @Etc
WHERE Email = @Email;
END
COMMIT
我可以调整其中任何一个以使用表变量（例如，我怀疑IF (@@ROWCOUNT = 0)需要完全删除表变量），但是使用表值输入是否明显表明我们应该选择第一个或第二个解决方案？如果不是，那么应该基于什么做出决定？
我有一个分区表，它包含一个行存储主键和一个非聚集列存储索引。这两个索引的前导键（虽然键的顺序对列存储来说并不重要）相同。更新统计信息时，SQL Server 会定期选择扫描列存储索引。这对我来说太耗时了，所以我尝试了
UPDATE STATISTICS My_Table
WITH PERSIST_SAMPLE_PERCENT = ON, SAMPLE 3 PERCENT
令我惊讶的是，统计信息更新仍然花费了很长时间。执行计划表明，列存储索引的扫描方式与之前相同。
所以，我有一个问题：从列存储索引读取时，UPDATE STATISTICS 中会忽略 PERSIST_SAMPLE_PERCENT 吗？自动统计信息更新似乎也存在这个问题。
更新：我怀疑实际上可能是删除的位图导致所有这一切出错。
我有一个带有多个 AG 的企业版 SQL Server 2022 集群。
其中两个 AG 将不同的实例视为主要实例。这两个 AG 都认为其次要实例是可读的，并且这样认为是正确的。
除了处于可读的辅助配置之外，没有任何东西可以使任何实例上的任何数据库变为只读。它们不是基本可用性组。
令人震惊的是：当我运行DBCC CHECKCATALOG针对可读辅助数据库的查询，同时连接到非该数据库主数据库的实例时，查询会失败，如下所示
消息 3906，级别 16，状态 8，第 1 行
无法更新数据库“DB NAME”，因为该数据库是只读的。
DBCC CHECKDB工作得很好！我找遍了所有地方，但没有发现任何有用的信息。
我该如何调试它？为什么DBCC CHECKDB（它是 的超集）可以DBCC CHECKCATALOG工作，而 却DBCC CHECKCATALOG失败了？
假设我有一个企业版数据库，它具有完全默认设置，只有普通的行存储表。没有 RCSI，没有快照隔离，也没有触发器。假设不需要行版本控制。
显然，这些假设意味着我不会为行版本控制支付额外的 14 字节/行成本。但是，可读 AG 次要副本在 SNAPSHOT 隔离下运行，而 SNAPSHOT 隔离需要行版本控制。因此，如果我将数据库放入可用性组并添加可读次要副本，我的数据库的哪些副本（如果有）将开始支付 14 字节/行的行版本控制成本？如果除了可读次要副本之外，我还有一个不可读次要副本，这种情况会改变吗？如果我进行故障转移并故障恢复会怎样？
之前链接的相关文档对此没有评论。我打算自己进行实验，但众所周知，AG 很容易出错，我不想得出错误的结论。
启动 auto_stats 扩展事件，过滤掉一些噪音，并准备监控它。
CREATE EVENT SESSION [AutoStatsTest] ON SERVER
ADD EVENT sqlserver.auto_stats(
WHERE ([duration]>1 AND [object_id] > 0) )
ADD TARGET package0.ring_buffer
ALTER EVENT SESSION [AutoStatsTest] ON SERVER
STATE = START
GO
找到一个时态表。我手头有一份 StackOverflow2010 数据库的副本，所以我直接对Votes系统进行了版本控制。
ALTER TABLE Votes ADD
ValidFrom DATETIME2 GENERATED ALWAYS AS ROW START HIDDEN
CONSTRAINT DF_InsurancePolicy_ValidFrom DEFAULT SYSUTCDATETIME(),
ValidTo DATETIME2 GENERATED ALWAYS AS ROW END HIDDEN
CONSTRAINT DF_InsurancePolicy_ValidTo DEFAULT CONVERT(DATETIME2, '9999-12-31 23:59:59.9999999'),
PERIOD FOR SYSTEM_TIME(ValidFrom, ValidTo);
GO
ALTER TABLE Votes
SET (SYSTEM_VERSIONING = ON);
GO
使用你的时态表，做一些能够触发统计信息自动更新的操作。这个方法对我来说很有效
SELECT TOP (1000) [BountyAmount]
FROM [StackOverflow2010].[dbo].[Votes]
WHERE [PostId] < [BountyAmount]
UPDATE [StackOverflow2010].[dbo].[Votes]
SET BountyAmount = 4*PostId
SELECT TOP (1000) [BountyAmount]
FROM [StackOverflow2010].[dbo].[Votes]
WHERE [PostId] < [BountyAmount]
现在检查扩展事件的 XML
SELECT target_data
FROM sys.dm_xe_session_targets AS xet
JOIN sys.dm_xe_sessions AS xe
ON (xe.address = xet.event_session_address)
WHERE xe.name = 'AutoStatsTest'
如果您像我一样，您会看到一些报告 100% sample_percentage 的字段。
<data name="sample_percentage">
<type name="int64" package="package0">
</type>
<value>
100
</value>
</data>
考虑到持续时间（在我那台破机器上只有 800 微秒），我知道这完全是胡扯。查阅了资料后sys.dm_db_stats_properties，我发现实际百分比远低于 100。
/*
Save yourself the pain of writing
the stats query
and just use sp_BlitzIndex from GitHub
*/
EXEC sp_blitzindex @databasename = 'StackOverflow2010', @tablename = 'Votes'
总而言之，auto_stats 扩展事件报告的时态表的 sample_percentage 值似乎有误。这是 SQL Server 的 bug 还是我的误解？如果是我的误解，那么我可以在哪里阅读更多内容？据我所知，单个扩展事件的文档非常缺乏。
我只在时态表中见过这种情况。我在 SQL Server 2022 的真实环境中（该表有数 TB 大小，所以当我看到主键统计信息的 100% 采样率时，我惊呼不已）和本地 2019 测试环境中都发现了这种情况。
添加列存储索引似乎有助于重现这种情况，但我不是 100% 确定。
CREATE NONCLUSTERED COLUMNSTORE INDEX IX_ColStore
on dbo.Votes
(
Id,
PostId
)
我确信这里确实存在一个 bug。然而，我尝试重现它时，结果并不一致。我怀疑你需要一个 TB 级的表格。
最后更新：我不再解释这一点了。该表的统计信息显示，用于更新统计信息的行数是实际执行计划（在生产环境中运行时实时捕获，扫描非聚集列存储索引）中实际行数的 90 倍。实际执行计划中的行数比表的行数少 10,000 倍，而 auto_stats 扩展事件显示表中 100% 的行已被读取。所有这些不可能同时成立。
我怀疑实际上可能是删除的位图导致了这一切。
众所周知，解码系统健康扩展事件中的 wait_resource 指针的含义是不可能的。但是，如果我在特定时间段内在该扩展事件中的所有长时间等待都报告相同的指针，那么这是否说明了什么？
我PAGELATCH_SH在这个时间段内经历了高等待时间，并认为所有指针相同的原因与此有关。我没有在这里包含 XML，因为我绝对确定它不会帮助回答这个问题。我只是想知道是否有这种情况，当它显然是一个指针时，我应该注意此扩展事件中的 wait_resource 值。
分区的好处文档列出了以下内容作为分区表的第一个性能优势
当分区列与表连接的列相同时，查询优化器可以更快地处理两个或多个分区表之间的等值连接查询。
同一页面稍后会就此主题进行更详细的说明，但这只是告诉您，连接未以完全相同方式分区的分区表不会获得与连接等效分区表相同的优化。当然，这与前面部分的说法无关；两种分区表方式之间的任何性能比较都与分区与不分区相比的优势无关。
这让我产生了一个疑问：连接等效分区表是否比连接具有相同前导聚集索引键的两个表更快？我很乐意接受实验性的答案或使用相关理论得出结论的答案。
我读过内部原理，也读过很多白皮书和博客，但我认为我没有在任何地方看到过这个问题。我对内部原理的理解让我得出结论，分区方法应该比非分区方法慢。毕竟，分区实际上所做的就是将另一个索引键放在键列表的前面。我自己的实验也发现了同样的结果。
今天，我深刻认识到，无法对基本可用性组的辅助设备进行损坏检查。鉴于这一限制，我如何知道可以安全地对 BAG 进行故障转移？据我所知，辅助设备可能已损坏。
对于 SQL Server 中的分区表，使用 min/max 函数或时存在一个臭名昭著的重大性能问题TOP。Microsoft在此处记录了此问题的解决方法。我确信此问题在 SQL Server 2022 中没有得到修复。如果给他们更多钱是一种解决方法，微软肯定会更新解决方法列表。
但是，这在 SQL Server 2022 之后有改变吗？我确信我在 2024 年看到了指向此 Connect 项目的有效链接。今天，即使在所有 Connect 项目都迁移到的现代Azure 建议中，我也找不到它。这向我表明，这个已有十年历史的错误在过去几年中发生了一些事情。
我自己无法回答这个问题，因为我无法访问 SQL Server 2025 或任何前沿的 Azure 产品，我听说 SQL Server 2025 的预览版已经发布。
假设 Windows 上的 SQL Server 2022 标准版，我根本看不到使用基本可用性组代替数据库镜像有什么好处。基本可用性组是否提供了数据库镜像没有的功能？
在这两种情况下：
我发现这两个功能之间的唯一区别是基本可用性组不能升级到企业版，并且数据库镜像已被正式弃用。
我知道基本可用性组比镜像更难设置，但我只想问基本可用性组相对于数据库镜像的好处。
在 SQL Server 2016 之前，对列存储索引进行分区被认为是强制性的，因为在插入/更新/删除期间对它们采取的锁定非常严格。但是，从 SQL Server 2016 开始，对列存储索引采取的锁定强度要小得多。那么，为什么对它们进行分区仍然被认为是最佳实践呢？
我知道一个技巧，你可以通过切换分区、构建聚集行存储索引、用列存储替换该索引，然后切换回该分区来改善对齐。然而，这只是一个温和的性能优化，很少能在重建后幸存下来，而且SQL Server 2022 的排序功能在很大程度上使其变得多余。
当我查看加速数据库恢复和读取已提交快照隔离的文档时，似乎加速数据库恢复的所有缺点都与读取已提交快照隔离相同。那么假设我已经启用了读取已提交快照隔离，那么加速数据库恢复的缺点是什么？
我怀疑 Azure 中默认启用加速数据库恢复和读取已提交快照隔离并非巧合。假设是 SQL Server 2019 或 SQL Server 2022。
如果您对分区有深入的了解，那么您将完全意识到分区不是行存储索引的性能特征。但是，每当我看到对此提出论点时，就像Gail Shaw 在这里最令人信服地所做的那样，论点都取决于将非分区索引与分区索引进行比较，其中两个索引都以分区键作为其前导键。像 Gail 这样的论点基于分区消除和以您的分区键作为第一个键来寻找非分区索引之间的性能差异很小。
这些论点很有说服力，但如果分区键不是分区索引的第一个键，情况又会怎样呢？在这种情况下，我们可以获得分区消除的好处，并且我们的前导键现在可用于搜索比我们将同一索引保留为非分区时要小得多的索引。这听起来应该比将同一索引保留为非分区时的性能有所提高。
总而言之，我的问题是：如果分区列不是索引的第一个键，那么对具有多个键的索引进行分区是否会提高性能？要回答这个问题，只需要一个例子，并附上一些理论来解释为什么结果是这样的。
假设一个表只包含整数并且具有聚集列存储索引。
CREATE TABLE cci_account
(
AccountKey int NOT NULL,
UnitSold int,
INDEX ColStore CLUSTERED COLUMNSTORE
);
那么看起来，在这样的表中，对一个列按另一个列分组求和总是很快，例如
SELECT
AccountKey,
SUM(UnitSold)
FROM
cci_account
GROUP BY
AccountKey;
为什么这么快？我对列存储架构的理解是，包含的段AccountKey不知道UnitSold其行上的值是什么。那么，SQL Server 如何能够如此快速地分组AccountKey？我无法想象任何算法可以实现这一点。
我一直在尝试表分区，发现了很多惊喜。我目前正在尽可能多地阅读文档，但文档数量多得令人震惊。我想我已经读完了六份白皮书中的第二份。我还没有在任何文档中看到过这个问题。
使用DROP_EXISTING = ON，似乎某些表可以就地分区。例如，我可以让它与唯一聚集索引一起工作。但是，我无法对主键执行相同的操作。本指南同意我的结论，并表示对具有主键的表进行分区需要先删除主键。这就像存在语法限制而不是功能限制。
我的问题是：什么时候可以对表进行分区而不在分区之前删除任何内容？换句话说，什么时候可以就地进行分区？
我并不是特意询问具体可以用什么方法做DROP_EXISTING。那只是我偶然发现的一种方法。
假设 SQL Server 2022。我不在乎操作是否在线。对于类似的事情，我有一个不同的问题。
CREATE PARTITION FUNCTION PF (integer)
AS RANGE RIGHT
FOR VALUES
(
10000, 20000, 30000, 40000, 50000
);
GO
CREATE PARTITION SCHEME PS
AS PARTITION PF
ALL TO ([PRIMARY]);
GO
CREATE TABLE dbo.T1
(
c1 integer NOT NULL,
c2 integer NOT NULL,
c3 integer NOT NULL,
CONSTRAINT PK_T1
PRIMARY KEY CLUSTERED (c1, c2, c3)
);
CREATE TABLE dbo.T2
(
c1 integer NOT NULL,
c2 integer NOT NULL,
c3 integer NOT NULL,
INDEX UIX_T2 UNIQUE CLUSTERED (c1, c2, c3)
);
GO
CREATE TABLE dbo.T3
(
c1 integer NOT NULL,
c2 integer NOT NULL,
c3 integer NOT NULL,
INDEX UIX_T3 UNIQUE NONCLUSTERED (c1, c2, c3)
);
GO
/* These work */
CREATE CLUSTERED INDEX UIX_T2 ON dbo.T2 (c1, c2, c3)
WITH (DROP_EXISTING = ON) ON PS(C1)
GO
CREATE NONCLUSTERED INDEX UIX_T3 ON dbo.T3 (c1, c2, c3)
WITH (DROP_EXISTING = ON) ON PS(C1)
GO
/* But I could never get the primary key to! */
在上面，您可以就地对唯一索引进行分区。但是，我还没有想到可以尝试对主键起作用的方法。我非常确定也REBUILD可以。
用简单的英语来说，“分区表和索引上的并行查询处理”和“分区表并行性”听起来是同一件事。然而，在 SQL Server 2022 中，标准版具有“分区表并行性”，但没有分区表和索引上的并行查询处理。这两个功能有何不同？
我已尽力查阅了相关文档，但尚未阅读全部白皮书。我尚未了解这两个功能的具体内容。
这个问题是本网站关于堆的评分最高的问题。它询问了堆的使用情况。但是，我认为非常大的堆（例如数千 GB）是一种特殊情况，值得单独提出一个问题。
随着聚集索引的大小增加，聚集索引惩罚也会增加，即从非聚集索引中获取剩余键所需的逻辑读取次数。堆的情况并非如此。我认为堆被不公平地忽略了，因为太多人要么从数据仓库中学习了所有的数据库设计（主键扫描，因此聚集索引，通常是一个好主意），要么从未在足够大的数据库上工作过，无法感受到拥有真正大表的代价。
这就产生了一个问题：索引良好的非常大的堆是否具有在索引良好的非常大的聚类表中找不到的实际用例？
为避免这个问题太过宽泛，我们采用以下约束。假设：
总的来说，这意味着您的缓冲池 RAM 限制为 128 GB，并且不会定期对主键进行大规模扫描。从磁盘读取整个堆会很麻烦，因此有关将表用作暂存表或仅备份表的任何答案都不适用。
CREATE TABLE persons
(
person_id int not null,
name TEXT
);
INSERT INTO persons VALUES
(1, 'Adam'),
(2, 'Paul'),
(3, 'Tye'),
(4, 'Sarah');
CREATE TABLE json_to_parse
(
person_id int not null,
block json
);
INSERT INTO json_to_parse VALUES
(1, '{"size": "small", "love": "x"}'),
(2, '{"size": "medium", "love": "xx"}'),
(3, '{"size": "big", "love": "xxx"}');
运行没有问题
SELECT
*
FROM
json_to_parse
CROSS JOIN LATERAL
json_to_record(json_to_parse.block) AS my_json(size TEXT, love TEXT)
INNER JOIN
persons
ON
persons.person_id = json_to_parse.person_id;
但这并不
SELECT
*
FROM
json_to_parse,
json_to_record(json_to_parse.block) AS my_json(size TEXT, love TEXT)
INNER JOIN
persons
ON
persons.person_id = json_to_parse.person_id;
我收到错误“对表“json_to_parse”的 FROM 子句条目的引用无效”
为什么第二个查询会出错？文档说得很清楚，LATERAL对于表值函数来说，这是可选的
中出现的表函数
FROM前面也可以加上关键字LATERAL，但对于函数来说，关键字是可选的；函数的参数FROM在任何情况下都可以包含对前面项提供的列的引用。
我最近一直在研究 Microsoft SQL Server 的列存储索引，我开始担心我的经验与行业经验不符。列存储索引旨在使聚合变得容易。人们经常说，出于这个原因，它们非常适合事实表。
这让我感到不安。根据我的经验，事实表不是聚合的。我制作的每个事实表的列表都是“主键后跟几个维度列，后跟我们存储的有关主键的每一点信息”的形式。然后它们被转储到 PowerBI 或 ThoughtSpot 等 BI 工具中，因此非技术人员可以根据维度进行筛选并找到他们想知道的任何信息。它们可能会不时聚合，但这肯定不是表格的主要用途。我预计这样的表格会有超过 100 列。
我所描述的表设计和访问模式是否符合事实表的预期？或者我所描述的是一种完全不同类型的表，而我不知道它的名称？