sql-server – 什么时候创建STATISTICS而不是创建索引更好?

前端之家收集整理的这篇文章主要介绍了sql-server – 什么时候创建STATISTICS而不是创建索引更好?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
@H_404_1@我已经找到了大量有关STATISTICS的信息:如何维护它们,如何手动或自动查询或索引创建它们等等.但是,我无法找到有关何时创建它们的任何指导或“最佳实践”信息:哪些情况从手动创建的STATISTICS对象中获益比从索引中获益更多.我已经看到手动创建过滤统计信息,帮助查询分区表(因为为索引创建的统计信息覆盖了整个表,而不是每个分区 – brillaint!),但肯定必须有其他方案可以从统计对象中受益不需要索引的细节,也不值得维护索引或增加阻塞/死锁的机会.

@JonathanFite在评论中提到了索引和统计之间的区别:

Indexes will help sql find the data faster by creating lookups that are sorted differently than the table itself. Statistics help sql determine how much memory/effort is going to be required to satisfy the query.

这是很好的信息,主要是因为它帮助我澄清了我的问题:

如何知道这一点(或与STATISTICS的行为和性质相关的任何其他技术信息)有助于确定何时选择CREATE STATISTICS而不是CREATE INDEX,特别是在创建索引时将创建相关的STATISTICS对象?只有STATISTICS信息而没有索引会更好地服务于什么情况?

如果可能的话,如果有一个STATISTICS对象比INDEX更适合的场景的工作示例,那将是超级有用的.

由于我是一名视觉学习者/思想家,我认为将STATISTICS和INDEX之间的差异并排看作可能有助于确定何时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 Index vs Statistic

SQL Server Statistics Questions We Were Too Shy to Ask

Statistics. Are multicolumn histograms possible?

**为了清楚起见,我没有这方面的答案,我实际上希望得到一些人的反馈意见,以提供似乎奇怪的错误信息在这里的互联网.

解决方法

你的问题围绕着 – 什么时候创建统计与创建索引(创建统计数据)是一件好事.

从我的sql server内部注释(sqlSkills类 – IE1和IE2)和SQL Server internals book,下面是我有限的理解:

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

sql Server使用基于成本的模型来尽快选择“足够好”的执行计划.忠诚度估计(估计要在每个步骤上处理的行数
查询执行是查询优化中最重要的因素,它会影响连接策略,内存授予要求,工作线程选择
以及访问数据时的索引选择.

sql Server在估计大数量时不会使用非聚簇索引.将需要KEY或RID循环操作,因此它维护索引(和列)的统计信息
将有助于这种估计.

统计数据有两个重要的事项:

>直方图仅存储最左侧统计(索引)列的数据分布信息.它还存储有关键值的多列密度的信息.基本上,
直方图仅存储最左侧统计列的数据分布.
>无论表大小如何,sql Server将在直方图中保留最多200个步骤.每个直方图步骤所覆盖的间隔随着表的增长而增加,这导致大表的“不太准确”的统计数据.

请记住,指数选择性是一个与密度成反比的指标,即色谱柱具有的唯一值越多,其选择性越高.

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

参考:

> Column Statistics Give the Optimizer an Edge by Kalen Delaney
> Statistics,Damned Lies,and Statistics – What is Statman?由康纳坎宁安

注意:像Paul WhiteAaron Bertrand这样的人可以为your good question提供更多颜色.

原文链接:https://www.f2er.com/mssql/79557.html

猜你在找的MsSQL相关文章