小编geo*_*tnz的帖子

我有一个大约 10 亿行的表。然后我创建一个索引如下：

CREATE NONCLUSTERED INDEX [IX_Index1] 
ON [dbo].[MyTable]( [CustomerID] ASC )  -- CustomerID is uniqueidentifier
WITH (DATA_COMPRESSION=PAGE);

这会产生 9.15GB 的索引（压缩），但是在创建索引时事务日志从空变为 158GB（没有其他数据库活动）。为什么使用的日志空间量远高于索引的结果大小？

数据库是可用性组中处于完全恢复模式的 SQLServer 2014 Enterprise。

更新 我删除并使用选项重新创建了索引SORT_IN_TEMPDB = ON。DB tlog 的事务日志写入结果为 10.4GB，tempdb tlog 为 1.27GB。

在几天的时间里，我们的数据库服务器上的被盗内存增长缓慢。它似乎稳定在 130-140GB 左右，此时我们开始遇到更大的问题，例如内存不足错误、多秒冻结和 AG 故障转移。问题在重新启动后大约一周开始出现。我已经开始记录被盗内存的历史，如下图：

查看sys.dm_os_memory_clerks，似乎其中大部分来自针对 NUMA 节点 0 上的缓冲池记录的非页面内存：

pages_kb随着时间的推移跟踪缓冲池的总数显示页面数量随着virtual_memory_committed_kb增长而下降。（4 月 13 日，服务器重新启动以进行 Windows 更新。缓冲池在大约一个小时内填充到 400GB）

有没有人见过这种行为？

我们运行的是 SQLServer 2016 CU12 13.0.5698.0 服务器是一个 64 核的 AWS EC2 i3.16xlarge 实例。我们有许多相同大小的其他集群都显示了这个问题。我们在 32 核 i3.8xlarge 实例上也有一些集群，它们也显示了被盗内存的增长，但它们最终不会停止/抛出内存不足错误。唯一的区别（规模除外）是 64 核服务器有 2 个 NUMA 节点。

更新： MS 表示 KB4536005 中的错误修复没有被反向移植到 SQL2016。