De acordo com os documentos do MS, a descrição para AVG_RANGE_ROWSé:
Número médio de linhas com valores de coluna duplicados em uma etapa do histograma, excluindo o limite superior. Quando DISTINCT_RANGE_ROWS é maior que 0, AVG_RANGE_ROWS é calculado dividindo RANGE_ROWS por DISTINCT_RANGE_ROWS. Quando DISTINCT_RANGE_ROWS é 0, AVG_RANGE_ROWS retorna 1 para a etapa do histograma.
Estou olhando para a última linha e se realmente for esse o caso, estou curioso para saber porque estou vendo um valor para AVG_RANGE_ROWSque não é igual 1quando DISTINCT_RANGE_ROWSestá 0nas etapas do histograma.
A estatística em questão é uma estatística de coluna criada pelo SQL Server quando a opção de criação automática de estatísticas está ativada. Estou em uma versão mais antiga do banco de dados, mas no patch mais recente - SQL Server 2014 SP3, CU4+GDR (12.0.6372.1).
É um pouco lamentável que quase tivemos um colapso na semana passada por causa de um plano de consulta abaixo do ideal. O resultado final foi grandes varreduras e concessões de memória inchadas. A reamostragem da estatística com um valor percentual mais alto resolveu o problema para nós por enquanto, mas estou mais curioso para saber se há exceções em torno da declaração inicial ou um problema conhecido (talvez resolvido usando um sinalizador de rastreamento?) evito que isso aconteça novamente para estatísticas criadas automaticamente, onde não temos controle sobre o tamanho da amostragem?
Conforme descrito em resposta ao Histograma mal formado causa estimativas ruins no Nested Loop , houve uma mudança na maneira como as estatísticas de amostra são calculadas e armazenadas, mais particularmente quando o dimensionamento é aplicado.
Como efeito colateral, o valor para
DISTINCT_RANGE_ROWSno seu caso é uma fração entre 0 e 1 (980,235 / 386212,6 = 0,002538071). A coluna tem um tipo exposto debigint, portanto, é arredondada para zero.Claramente, não pode haver valores distintos de zero quando o intervalo contém um número diferente de zero de linhas.
Só podemos esperar que essas discrepâncias sejam esclarecidas em algum momento; embora seja difícil imaginar exatamente como isso pode parecer sem uma alteração potencialmente importante do tipo de dados, estendendo-se também para
sys.dm_db_stats_histogram(disponível no SQL Server 2016 e posterior).Quanto ao que você faz a respeito, se estiver convencido de que isso não é apenas um problema de exibição e está realmente causando estimativas ruins, você deve reportá-lo como uma regressão.