A criação de estatísticas em uma tabela columnstore clusterizada sempre parece ler a tabela inteira, mesmo que eu peça uma pequena amostra. Por que é isso?
relate perguntas
-
SQL Server - Como as páginas de dados são armazenadas ao usar um índice clusterizado
-
Preciso de índices separados para cada tipo de consulta ou um índice de várias colunas funcionará?
-
Quando devo usar uma restrição exclusiva em vez de um índice exclusivo?
-
Quais são as principais causas de deadlocks e podem ser evitadas?
-
Como determinar se um Índice é necessário ou necessário
Estatísticas de amostra em um heap ou b-tree usam
TABLESAMPLE SYSTEM. Esse algoritmo emprega uma varredura ordenada por alocação e escolhe as páginas da varredura para amostra. Todas as linhas nas páginas selecionadas contribuem para o histograma de estatísticas. Você pode encontrar detalhes do processo de seleção em minha resposta a Comportamento estranho com tamanhos de amostra para atualizações de estatísticas .O columnstore clusterizado é implementado de maneira
TABLESAMPLE SYSTEMdiferente. Existem duas estratégias de amostragem separadas:O primeiro algoritmo é usado apenas ao selecionar linhas para a fase de compilação do dicionário primário de uma criação de índice columnstore (destacado no plano de compilação columnstore clusterizado abaixo).
A implementação é otimizada para desempenho, mas abre mão de alguma precisão. Ele usa amostragem por conglomerados semelhante em conceito ao método para heaps e b-trees: um conjunto de grupos de linhas é selecionado aleatoriamente, seguido por uma amostra aleatória de linhas dentro de cada grupo selecionado. O número de linhas e grupos de linhas selecionados é derivado da porcentagem de amostragem. Os grupos de linhas que não são selecionados na etapa inicial não são lidos do disco.
A fase de compilação do dicionário primário pode ser ignorada no SQL Server 2019 ou posterior habilitando o sinalizador de rastreamento global 11611.
O segundo algoritmo é sempre usado para compilações de estatísticas. Ele usa amostragem em nível de linha verdadeiramente aleatória, mas tem um custo de E/S e CPU mais alto. Ele verifica todos os segmentos de uma coluna e seleciona aleatoriamente um subconjunto de linhas. Isso pode produzir histogramas mais precisos do que para b-trees e heaps, que apenas amostram páginas inteiras.
O objeto de estatística final refletirá a taxa de amostragem desejada. A implementação torna isso mais difícil de ver do que com heaps ou b-trees porque todos os segmentos são lidos durante o processo.