我有一个包含 2200 万条记录的表。
我注意到一列的统计数据有偏差，即使该列具有恒定分布：事实上，每个值都重复了两次。
为了帮助您想象这种情况，请考虑一个表，其中包含另一个表的每个唯一 ID 的签入和签出日期（2 条不同的记录）。
这些是完整扫描的统计数据：
这些是自动采样的统计数据：
为什么会有这种奇怪的行为？是否有一些经验法则来确定正确的采样率或是否需要全扫描？我应该为某些统计信息创建一个带有全扫描的统计更新作业吗？如果是这样的话，我怎么知道哪些统计数据需要这种处理？
附加信息：
- 该列没有外键约束
- 该列是一个
numeric(14,0) NULL
假设有人给你一本一百万整数的书，让你根据十个样本数来猜测整体分布。您收到的十个样本数字是 1、1、125000、125000、250000、250000、375000、375000、500000 和 500000。一个完全合理的猜测是这本书包含 500000 个成对的唯一整数，范围从 1 到 500000。另一个同样有效的猜测是这本书包含五个唯一的整数，每个整数出现 200000 次。对于您的数据分布，SQL Server 正在根据更接近后一种解释的示例对您的数据进行推断。构建直方图的算法不适用于所有可能的采样数据分布，包括每个唯一整数恰好出现两次的分布。
我知道的唯一经验法则是正确的采样率至少等于为您提供可接受的查询或系统性能的采样率。我发现 DBA 使用 100% 的采样率来避免这种分析，对于不太大的表来说，这是一个非常合理的捷径。
您可以考虑用基于两个基础表构建的可更新视图替换您的表。每个基础表都可以包含一半的数据。SQL Server 将为每个表构建单独的统计对象，您无需调整统计信息即可获得更好的性能。我不能说这是否适合您的特定情况。
这是您所描述问题的常见解决方案。对于另一个选项，SQL Server 2016 SP1 CU4为命令引入了PERSIST_SAMPLE_PERCENT关键字。
STATISTICS您可以使用它来指示 SQL Server 在触发自动统计更新时始终以特定速率对该列的统计信息进行采样。如果禁用了异步统计更新，那么请记住，对于使用您的列的查询，查询编译时间有时可能会很长。通常的答案是监控您的工作负载是否存在不可接受的查询性能，确定哪些查询存在统计问题，并通过更改统计信息来修复这些问题。如果您想积极主动，可以考虑分析生产副本的统计数据。首先获取数据库中所有相关列的抽样统计信息，并将所有密度向量保存到一个表中。你可以用它
DBCC SHOW_STATISTICS WITH DENSITY_VECTOR来做到这一点。然后更新所有相同的统计数据FULLSCAN并保存这些密度向量。然后您可以比较密度向量以找到具有最大差异的统计对象。这不会找到所有统计问题，但会找到与您在此问题中观察到的类似的问题。对列的统计信息执行完整扫描更新允许 SQL Server 了解列的确切性质，而默认扫描查看表的“具有统计意义的”行样本。在您的表中，“具有统计意义”的行样本导致数据不完整。
对于具有非典型值分布的表，全扫描统计更新几乎总是会产生更准确的直方图。没有全面的“最佳”选择；默认采样率有助于平衡大多数表的统计更新性能和查询性能。
了解列中包含的数据将使您能够确定完整扫描是否会产生更好的统计数据。
作为经验法则，我总是设置每晚或每周运行的统计重新扫描作业，除非有一些要求将 I/O 降至最低，否则我设置该作业以对这些统计进行 FULLSCAN 更新。我创建的作业仅更新已收到“x”次更新/插入/删除的表，并且在“x”时间内没有进行统计更新。在低活动期间按计划运行作业，在大多数情况下，会阻止 SQL Server 在高活动期间运行统计更新。
我写了一篇博客文章，展示了我如何通过 中的存储过程
master和 SQL Server 代理作业更新统计信息：http ://www.sqlserver.science/maintenance/statistics-update-job/