什么时候创建统计信息而不是创建索引更好？

 Thingy           PROs                             CONs
-------          ----------                       -------------------
INDEX            * Can help sorts.                * Takes up space.
                 * Contains data (can             * Needs to be maintained (extra I/O).
                   "cover" a query).              * More chances for blocking / dead-locks.

STATISTICS       * Takes up very little space.    * Cannot help sorts.
                 * Lighter maintenance / won't    * Cannot "cover" queries.
                   slow down DML operations.
                 * Does not increase chances
                   of blocking / dead-locks.
 

#1 楼

您的问题围绕着-创建统计信息与创建索引（创建统计信息）何时是一件好事。

从我的sql server内部笔记（SQLSkills类IE1和IE2）和SQL Server内部这本书对我的理解有限：

SQL Server统计信息只不过是包含有关索引键值和常规列值的重要信息的系统对象。

SQL Server使用一个基于成本的模型，以尽快选择“足够好”的执行计划。可伸缩性估计（估计
查询执行的每个步骤上要处理的行数）是查询优化中最重要的因素，这反过来会影响连接策略，内存授予要求，工作线程选择以及访问数据时的索引选择。

SQL Server估计较大的数字时，它将不使用非聚集索引。 KEY或RID循环操作将是必需的，因此它维护了索引（和列）的统计信息，这将有助于这种估算。

关于统计信息有2个重要的事项：


直方图仅存储有关最左侧统计信息（索引）列的数据分布的信息。它还存储有关键值的多列密度的信息。因此，基本上，
直方图只存储最左侧统计信息列的数据分布。

SQL Server将在直方图中最多保留200个步骤，而与表的大小无关。随着表的增加，每个直方图步骤所覆盖的间隔也会增加，这会导致大型表的统计信息“准确性下降”。

请记住，索引选择性是与密度成反比的度量，即值越独特列具有更高的选择性。


当特定查询不经常运行时，您可以选择创建列级统计信息而不是索引。列级统计信息帮助
Query Optimizer可以找到更好的执行计划，即使这些执行计划由于所涉及的索引扫描不是最佳选择。同时，统计信息不会在数据修改操作期间增加开销，并且
有助于避免索引维护。此方法仅适用于很少执行的查询。

参考：



列统计信息让Kallen Delaney提供优化器优势

统计，该死的谎言和统计–什么是Statman？注意：像Paul White或Aaron Bertrand这样的人可以发出声音，为您的好问题提供更多色彩。

#2 楼

我想说的是，当您需要能够根据字段限制数据量/快速获取正确的数据时，需要一个索引。

需要优化器时就需要统计信息为了理解数据的本质，以便能够以最佳方式执行操作。

我发现，经过过滤的统计信息会在数据中的偏斜严重影响计划时提供帮助，例如堆栈溢出示例中，很少有用户拥有大量帖子，因此仅使用每个用户的平均帖子并不是最佳估计。因此，您可以基于用户名在userId上创建过滤的统计信息，然后SQL Server应该知道，当该用户名出现在查询中时，这就是它将获得的用户ID，并且应该能够弄清楚posts表中的索引字段将具有该id的大量行，因为在那里存在直方图。如果使用平均值，则不可能做到这一点。

#3 楼

从Itzik Ben-Gan撰写的70-461培训手册中

只有少数可能的原因来手动创建统计信息。一个示例是查询谓词包含具有跨列关系的多个列时。多列的统计信息可以帮助改进查询计划。多列统计信息包含跨列密度，这在单列统计信息中不可用。但是，如果列已在同一索引中，则多列统计信息对象已存在，因此您不应手动创建其他列。