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

我发现了很多有关什么 的信息STATISTICS：如何维护它们，如何从查询或索引手动或自动创建它们，等等。但是，我无法找到有关何时使用的任何指导或“最佳做法”信息创建它们：在什么情况下，手动创建的STATISTICS对象比从Index中受益更多。我已经看到了手动创建的筛选统计信息，可以帮助对分区表进行查询（因为为索引创建的统计信息涵盖整个表，而不是每个分区-太小了！），但是肯定还有其他情况可以从统计对象中受益不需要索引的详细信息，也不需要花费维护索引或增加阻塞/死锁机会的成本。

@JonathanFite在评论中提到索引和统计数据之间的区别：

索引将通过创建与表本身排序不同的查找来帮助SQL更快地找到数据。统计信息可帮助SQL确定满足查询所需的内存/工作量。

那是个很棒的信息，主要是因为它可以帮助我阐明我的问题：

如何知道这（或在任何其他技术信息什么 S和如何 S的相关的行为和性质STATISTICS）帮助确定何时选择CREATE STATISTICS在CREATE INDEX创建索引将创建相关的时候，尤其是STATISTICS对象？仅具有统计信息而不具有索引会更好地服务于哪种情况？

如有可能，提供一个工作场景示例，说明该STATISTICS对象比物体更合适，这对超级骗子很有帮助INDEX。

因为我是一个视觉学习者/思想家，所以我认为并排查看es STATISTICS和INDEXes 之间的差异可能会有所帮助，这是帮助确定何时STATISTICS是更好选择的一种可能方法。

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.

以下是我在寻找此资源时发现的一些资源，其中一些资源甚至问了同样的问题，但未得到回答：

SQL Server索引与统计

SQL Server统计信息问题我们不敢问

统计。多列直方图可能吗？

**明确地说，我对此没有答案，实际上我希望从一些人那里得到反馈，以在Internet上的此处提供似乎奇怪地缺少的信息。

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

从我的sql server内部结构笔记（SQLSkills类IE1和IE2）和SQL Server内部结构书中，以下是我的有限理解：

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

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

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

关于统计信息，有2件重要的事情：

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

2. 无论表的大小如何，SQL Server最多将保留200个直方图步骤。随着表的增加，每个直方图步骤所覆盖的间隔也会增加，这会导致大型表的统计信息“准确性较低”。

   请记住，索引选择性是一个与密度成反比的度量，即列的唯一值越多，其选择性就越高。

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

参考：

• 列统计信息使优化器处于优势地位，作者Kalen Delaney
• 统计，该死的谎言和统计–什么是Statman？由Conor Cunningham

注意：诸如Paul White或Aaron Bertrand之类的人可以发出声音，为您的好问题提供更多色彩。

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

当您需要优化器来了解数据的性质以便能够以最佳方式执行操作时，您需要统计信息。

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

来自Itzik Ben-Gan的70-461培训书

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