在日期列中使用 NULL 时，多索引的 SQL Server 统计信息不正确答案

【问题标题】：SQL Server statistic for a multi index incorrect when using NULL in a date column在日期列中使用 NULL 时，多索引的 SQL Server 统计信息不正确
【发布时间】：2021-03-19 16:16:04
【问题描述】：

SQL Server 有一个关于索引的统计信息，它错误地估计了行数，这个表（和谓词）用于许多不同的查询。这会导致这些查询执行不佳，因为统计数据期望查询返回 5 行，而它返回 431268。

查询：

SELECT COUNT(BuildRecord.BuildRecordID)
FROM dbo.BuildRecord
WHERE BuildRecord.ContainedToDT IS NULL
  AND BuildRecord.RfBuildRecordTypeID = 2 
  AND BuildRecord.IsEdited = 0

昨天使用 FULLSCAN 更新了统计数据：

索引有

在BuildRecord 表中，ContainedToDT 是一个 NULLABLE DATETIMEOFFSET，RfBuildRecordTypeID 是一个 NOT-NULL SMALLINT 和 IsEdited 是一个 NOT-NULL TINYINT。

索引如下：

CREATE NONCLUSTERED INDEX [IM_ContainedToDT_RfBuildRecordTypeID_IsEdited] 
ON [dbo].[BuildRecord] ([ContainedToDT] ASC, [RfBuildRecordTypeID] ASC, [IsEdited] ASC)
INCLUDE([InvPackCreatedID], [InvPackConsumedID]) 
       WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, 
             SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, 
             ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF) ON [PRIMARY]

SQL Server 版本是 Microsoft SQL Server 2019 (RTM-CU8) (KB4577194) 兼容模式为 SQL Server 2016 (130)

任何建议或想法将不胜感激。

【问题讨论】：

标签： sql-server database-indexes

【解决方案1】：

将兼容性模式更改为 SQL Server 2019 (150) 似乎可以让我更好地估计这个统计数据。

强制查询使用 Legacy Cardinality Estimation

【讨论】：

2019 似乎提供了更好的性能，因为估计行和计划并行；您是否尝试过在 2016 年兼容性中强制使用旧基数估计器？
感谢 Stu，使用 FORCE_LEGACY_CARDINALITY_ESTIMATION 提示的执行计划看起来更类似于 2019 年的执行计划。将其添加到上面的帖子中
这很有趣。我想知道在 2016 兼容模式下使用 2019 是否可能存在错误，我想知道在 sql2016 上会发生什么，可能比较方便。 2919 遇到的问题比你想象的要多！