[更新：此问题描述了SQL Server 2019 累积更新 5 中已修复的错误。]

考虑以下重现示例（fiddle）：

CREATE FUNCTION dbo.Repro (@myYear int)
RETURNS datetime
AS
BEGIN
    IF @myYear <> 1990
    BEGIN
        RETURN NULL
    END

    DECLARE @firstOfYear datetime;
    SET @firstOfYear = DATEFROMPARTS(@myYear, 1, 1);
    
    IF DATEDIFF(day, @firstOfYear, @firstOfYear) <> 0
    BEGIN
        RETURN NULL
    END

    RETURN @firstOfYear
END
SELECT dbo.Repro(0);

显然，如果输入是 ，该函数应该返回 1990 年 1 月的第一天1990，NULL否则返回。是的，我知道这DATEDIFF(day, @firstOfYear, @firstOfYear) <> 0是一个荒谬的操作。这是一个演示潜在错误的mcve，而不是生产代码。

现在让我们SELECT dbo.Repro(0)在 SQL Server 2017 和 SQL Server …

SQL Server 2019 CTP3.1引入了解决最后一页插入争用的优化。这采用名为的索引选项的形式OPTIMIZE_FOR_SEQUENTIAL_KEY。

有人认为这可能是Bw-Tree或Bz-Tree的改编。然而，这些依赖于可变大小的页面，而当前的存储引擎需要固定大小的页面。

优化是如何实现的？这种优化如何改变当前的 B 树算法？在什么情况下我会选择不部署此选项？

研究

反向密钥方法的专利。

我使用 DBCC PAGE 快速浏览了一下，比较了 2017 年与 2019 年和 2019 年在 int IDENTITY 列的唯一聚集索引上使用和不使用 OPTIMIZE_FOR_SEQUENTIAL_KEY 的情况。没有什么可以明显地解释这种新行为。这让我觉得它是一个算法的东西，而不是一个结构的东西，这是有道理的。

来自 MS的博客文章。

此功能似乎以检测和避免车队为中心。

SQL Server 2019 CTP 2.3 向 sys.databases 添加了一些新列，包括 is_result_set_caching_on：

SQL Server 2019 的新增功能和ALTER DATABASE 页面中尚未记录。

我尝试使用与加速数据库恢复相同的语法只是为了笑：

ALTER DATABASE StackOverflow2013 SET RESULT_SET_CACHING ON;

但没有运气：

Msg 5058, Level 16, State 12, Line 8
Option 'RESULT_SET_CACHING' cannot be set in database 'StackOverflow2013'.

问题

我们已启用 sp_configure 'tempdb metadata memory-optimized' = 1，现在 tempdb 元数据在我们的一台服务器上占用了 400 GB 以上，并且还在继续增长。内存使用量有所下降，但通常它的内存使用量会不断增加。我们已经有几次服务器实际上崩溃了，因为其他系统进程没有足够的内存来修改 tempdb，这导致整个服务器宕机。

我问的问题

如何防止 SQL Server 内存中优化的 tempdb 元数据不断增长并使我的服务器崩溃？如果有的话，我可以查看哪些其他信息来找到消耗如此多内存的内容？

有关问题的数据

sys.dm_os_memory_clerks

以下查询当前返回 438 GB。

SELECT SUM(domc.pages_kb / 1024.0 / 1024.0) AS pages_gb
FROM sys.dm_os_memory_clerks AS domc
WHERE domc.type LIKE 'MEMORYCLERK_XTP'

sys.dm_db_xtp_memory_consumers

以下查询提供的数据是内存的最大使用量（290 GB）是 memory_consumer_id 为 113 - 'LOB Page Allocator'。它没有object_id 或xtp_object_id，所以我猜它是一个数据库范围的对象。

SELECT ddxmc.memory_consumer_id
     , ddxmc.memory_consumer_type_desc
     , ddxmc.memory_consumer_desc
     , ddxmc.object_id
     , ddxmc.xtp_object_id
     , ddxmc.used_bytes / 1024.0 / 1024.0 / 1024.0 AS used_gb
FROM sys.dm_db_xtp_memory_consumers AS ddxmc
ORDER BY ddxmc.allocated_bytes …

在工作原理：SQL Server 2012 数据库引擎任务计划中，Bob Dorr 解释了 SQL Server 2012 中工作调度程序分配的一些更改。他提到一些改进仅在企业版中可用。这些差异在 SQL Server 2019 中是否仍然存在？

如果这很重要，我会问这个问题，因为我发现 SQL Server 2017 标准版实例上可能存在调度程序效率低下的问题，该实例计划未来升级到企业版。如果升级到企业版可以解决问题，我不想尝试对标准版进行调查。

我尝试将数据库从本地计算机 v15 (2019) 上的 Sql Server 克隆到服务器计算机 v14(2017)。我做了一个 .bak 文件，当我尝试在服务器端导入时，它显示：

System.Data.SqlClient.SqlError：数据库已在运行版本 15.00.4083 的服务器上备份。该版本与运行版本 14.00.2037 的服务器不兼容。在支持备份的服务器上还原数据库，或使用与该服务器兼容的备份。(Microsoft.SqlServer.SmoExtended)

14-15 Sql Server 版本是否有“兼容”备份模式？

本地（在 docker、Linux 上）：

Microsoft SQL Server 2019 (RTM-CU8-GDR) (KB4583459) - 15.0.4083.2 (X64) 2020 年 11 月 2 日 18:35:09 版权所有 (C) 2019 Microsoft Corporation Developer Edition（64 位）Linux (Ubuntu 18.04.5)长期支持）

远程（在 Windows Server 上）

Microsoft SQL Server 2017 (RTM-GDR) (KB4583456) - 14.0.2037.2 (X64)
2020 年 11 月 2 日 19:19:59 版权所有 (C) 2017 Microsoft Corporation 标准版（64 位），位于 Windows Server 2019 Standard 10.0（内部版本 …

我一直在网上寻找如何下载 SQL Serer 2019 Developer 版本。目前，在微软网站上他们只有 2022 版本，所以我想知道如何下载旧版本。我上次愚蠢地没有下载离线安装程序

在 SQL Server 2019 中，Microsoft 引入了对和数据类型的UTF-8 支持，并表示：CHARVARCHAR

此功能可显着节省存储空间，具体取决于使用的字符集。例如，使用支持 UTF-8 的归类将带有 ASCII 字符串的现有列数据类型从 NCHAR(10) 更改为 CHAR(10)，意味着存储需求减少了近 50%。这种减少是因为 NCHAR(10) 需要 22 个字节的存储空间，而 CHAR(10) 需要 12 个字节来存储相同的 Unicode 字符串。

UTF-8似乎支持每个脚本，所以基本上我们就可以开始在存储Unicode数据varchar和char列。正如文档中所说，这可以减少表和索引的大小，从那里我们可以获得更好的性能，因为读取的数据量更少。

我想知道这是不是意味着我们可以停止使用nvarchar和nchar列，它实现UTF-16？

任何人都可以指出一个场景和原因，不要使用带有UTF编码的 char 数据类型并继续使用 n-chars数据类型吗？

SQL Server 2019 引入了一个新的（且未记录的）系统存储过程：

sys.xp_delete_files

这个新的扩展存储过程究竟有什么作用？它与xp_delete_file已经存在多年的有什么不同？它代替xp_delete_file吗？

我们开始在 Windows 2019 上安装和配置 SQL Server 2019，安装后注意到一个名为“AzureAttestService”的新服务正在运行并设置为自动。服务也将描述和组字段列为 AzureAttestService。下面是几个问题：

• 这项服务的目的是什么？
• 与 SQL Server 2019 有什么关系？
• 停止和禁用此服务有什么负面影响吗？

我已经研究过，但没有找到关于 AzureAttestService 的太多信息。如果有人有关于这项服务的信息并且可以分享，我将不胜感激。

谢谢！