Quando é melhor criar ESTATÍSTICAS em vez de criar um Índice?

Encontrei muitas informações sobre o que STATISTICS são: como elas são mantidas, como podem ser criadas manual ou automaticamente a partir de consultas ou índices e assim por diante. Porém, não consegui encontrar nenhuma orientação ou informações sobre "melhores práticas" sobre quandopara criá-los: quais situações se beneficiam mais com um objeto STATISTICS criado manualmente do que com um índice. Eu vi estatísticas filtradas criadas manualmente, ajudando as consultas em tabelas particionadas (porque as estatísticas criadas para os índices cobrem toda a tabela e não são por partição - brillaint!), Mas certamente deve haver outros cenários que se beneficiariam de um objeto de estatística enquanto sem precisar dos detalhes de um índice, nem valer o custo de manter o índice ou aumentar as chances de bloqueios / bloqueios.

@JonathanFite, em um comentário, mencionou uma distinção entre índices e estatísticas:

Os índices ajudarão o SQL a encontrar os dados mais rapidamente, criando pesquisas classificadas de maneira diferente da própria tabela. As estatísticas ajudam o SQL a determinar quanta memória / esforço será necessário para satisfazer a consulta.

Essa é uma ótima informação, principalmente porque me ajuda a esclarecer minha pergunta:

Como esse conhecimento (ou qualquer outra informação técnica sobre o que é e como s relacionadas com os comportamentos e natureza STATISTICS) ajudam a determinar quando para escolher CREATE STATISTICSao longo CREATE INDEX, especialmente quando a criação de um índice irá criar o relacionado STATISTICSobjeto? Qual cenário seria melhor atendido com apenas as informações ESTATÍSTICAS e sem o Índice?

Seria super útil, se possível, ter um exemplo prático de um cenário em que o STATISTICSobjeto se encaixa melhor que um INDEX.

Como sou um aprendiz / pensador visual, achei que poderia ajudar a ver as diferenças entre STATISTICSe INDEXes, lado a lado, como um possível meio de ajudar a determinar quando STATISTICSé a melhor escolha.

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.

A seguir, alguns recursos que eu encontrei ao procurar isso, um que até faz a mesma pergunta, mas não foi respondido:

Índice do SQL Server vs estatística

Perguntas sobre estatísticas do SQL Server Estávamos com vergonha de perguntar

Estatisticas. Os histogramas de várias colunas são possíveis?

** Para ser claro, eu não tenho uma resposta para isso e, na verdade, estou procurando obter feedback de algumas pessoas, para fornecer o que parece estar estranhamente faltando informações aqui nas interwebs.

Sua pergunta gira em torno - Quando é bom apenas criar estatísticas versus criar índice (que cria estatísticas).

Nas minhas anotações internas do sql server (SQLSkills class- IE1 e IE2) e no livro interno do SQL Server , abaixo está meu entendimento limitado :

As estatísticas do SQL Server nada mais são do que objetos do sistema que contêm informações vitais sobre os valores da chave de índice e os valores regulares da coluna.

O SQL Server usa um modelo baseado em custo para escolher um plano de execução "suficientemente bom" o mais rápido possível. A estimativa de cardanilidade (estimativa do número de linhas a serem processadas em cada etapa da execução da consulta) é o fator mais importante na otimização de consultas, que afeta a estratégia de junção, o requisito de concessão de memória, a seleção de encadeamento de trabalho e a escolha de índices ao acessar dados .

O SQL Server não usará índices não clusterizados quando estima que um grande não. de operações de loop KEY ou RID serão necessárias, portanto, ele mantém estatísticas sobre índices (e colunas) que ajudarão nessas estimativas.

Há duas coisas importantes sobre as estatísticas:

1. O histograma armazena informações sobre a distribuição de dados SOMENTE para a coluna de estatísticas mais à esquerda (índice). Ele também armazena informações sobre a densidade de várias colunas dos valores-chave. Portanto, essencialmente, o histograma armazena a distribuição de dados apenas para a coluna de estatísticas mais à esquerda.

2. O SQL Server manterá no máximo 200 etapas no histograma, independentemente do tamanho da tabela. Os intervalos cobertos por cada etapa do histograma aumentam à medida que a tabela cresce, o que leva a estatísticas "menos precisas" para tabelas grandes.

   Lembre-se de que a seletividade do índice é uma métrica inversamente proporcional à densidade, ou seja, quanto mais valores únicos uma coluna tiver, maior será sua seletividade.

Quando consultas específicas não são executadas com muita frequência, você pode optar por criar estatísticas no nível da coluna em vez de um índice. As estatísticas no nível da coluna ajudam o Query Optimizer a encontrar melhores planos de execução, mesmo que esses planos sejam abaixo do ideal devido às verificações de índice envolvidas. Ao mesmo tempo, as estatísticas não adicionam uma sobrecarga durante as operações de modificação de dados e ajudam a evitar a manutenção do índice. Essa abordagem funciona apenas para consultas raramente executadas.

Referir :

• Estatísticas da coluna Dê uma vantagem ao otimizador de Kalen Delaney
• Estatísticas, Mentiras Malditas e Estatísticas - O que é Statman? de Conor Cunningham

Nota: Alguém como Paul White ou Aaron Bertrand pode entrar em cena para dar mais cor à sua boa pergunta .

Eu diria que você precisa de um índice quando precisar limitar a quantidade de dados / obter os dados corretos rapidamente com base no (s) campo (s).

Você precisa de estatísticas quando precisa do otimizador para entender a natureza dos dados para poder executar as operações da melhor maneira possível.

O que eu descobri, as estatísticas filtradas ajudam quando você tem distorções nos seus dados que afetam fortemente o plano; por exemplo, no estouro de pilha, poucos usuários têm um grande número de postagens; portanto, usar apenas postagens médias por usuário não é realmente a melhor estimativa. Portanto, você pode criar uma estatística filtrada no userId com base no nome do usuário e, em seguida, o SQL Server deve saber que, quando esse nome de usuário está na consulta, esse é o ID do usuário que ele receberá e deve ser capaz de descobrir que o O campo indexado na tabela de postagens terá uma quantidade enorme de linhas com esse ID porque o histograma existe lá. Com as médias, não é possível fazer isso.

De 70-461 Livro de treinamento de Itzik Ben-Gan

Existem apenas alguns motivos possíveis para criar estatísticas manualmente. Um exemplo é quando um predicado de consulta contém várias colunas que têm relacionamentos entre colunas; as estatísticas nas várias colunas podem ajudar a melhorar o plano de consulta. As estatísticas em várias colunas contêm densidades entre colunas que não estão disponíveis nas estatísticas de coluna única. No entanto, se as colunas já estiverem no mesmo índice, o objeto de estatísticas de várias colunas já existe, portanto, você não deve criar um adicional manualmente.