Estou executando esta consulta no banco de dados AdventureWorks2012 :
SELECT
s.SalesOrderID,
d.CarrierTrackingNumber,
d.ProductID,
d.OrderQty
FROM Sales.SalesOrderHeader s
JOIN Sales.SalesOrderDetail d
ON s.SalesOrderID = d.SalesOrderID
WHERE s.CustomerID = 11077
Se eu olhar para o plano de execução estimado, vejo o seguinte:
A busca de índice inicial (canto superior direito) está usando o índice IX_SalesOrderHeader_CustomerID e pesquisando no literal 11077. Tem uma estimativa de 2,6192 linhas.
Se eu usar DBCC SHOW_STATISTICS ('Sales.SalesOrderHeader', 'IX_SalesOrderHeader_CustomerID') WITH HISTOGRAM, isso mostra que o valor 11077 está entre as duas chaves amostradas 11019 e 11091.
O número médio de linhas distintas entre 11019 e 11091 é 2,619718, ou arredondado para 2,61972, que é o valor das linhas estimadas mostradas para a busca do índice.
A parte que não entendo é o número estimado de linhas para a busca de índice clusterizado na tabela SalesOrderDetail.
Se eu correr DBCC SHOW_STATISTICS ('Sales.SalesOrderDetail', 'PK_SalesOrderDetail_SalesOrderID_SalesOrderDetailID'):
Portanto, a densidade do SalesOrderID (no qual estou entrando) é 3,178134E-05. Isso significa que 1/3.178134E-05 (31465) é igual ao número de valores exclusivos de SalesOrderID na tabela SalesOrderDetail.
Se houver 31465 SalesOrderID exclusivos em SalesOrderDetail, com uma distribuição uniforme, o número médio de linhas por SalesOrderID é 121317 (número total de linhas) dividido por 31465. A média é 3,85561
Portanto, se o número estimado de linhas a serem percorridas for 2,61972 e a média a ser retornada em 3,85561, acho que o número estimado de linhas seria 2,61972 * 3,85561 = 10,10062.
Mas o número estimado de linhas é 11,4867.
Acho que meu entendimento da segunda estimativa está incorreto e os números diferentes parecem indicar isso. o que estou perdendo?
Usando o estimador de cardinalidade do SQL Server 2012, a seletividade da junção orienta o número estimado de linhas no lado interno da junção de loops aninhados, e não o contrário.
O número 11,4867 é derivado (para exibição no plano de execução) dividindo a cardinalidade estimada calculada da saída da junção (30,0919) pelo número de iterações (2,61972). O resultado, usando aritmética de ponto flutuante de precisão simples, é 11,4867 .
É realmente tão simples quanto isso. Observe que a seletividade de junção (lógica) é independente da escolha do operador de junção física. Permanece o mesmo se a junção for executada usando um operador físico Nested Loops, Hash ou Merge Join.
No SQL Server 2012 e anteriores, a seletividade de junção (como um todo) é estimada usando os
SalesOrderIDhistogramas de cada tabela (calculados para cada etapa do histograma, após o alinhamento do limite da etapa usando interpolação linear conforme necessário). OSalesOrderIDhistograma associado àSalesOrderHeadertabela também é ajustado para o efeito de escala doCustomerIDfiltro independente.Isso não quer dizer que haja algo fundamentalmente 'errado' com o cálculo alternativo proposto na pergunta; apenas faz um conjunto diferente de suposições. Sempre haverá maneiras diferentes de calcular ou combinar estimativas para uma determinada sequência de operações lógicas. Não há garantia geral de que diferentes métodos estatísticos aplicados aos mesmos dados produzirão as mesmas respostas ou que um método sempre será superior ao outro. Inconsistências resultantes da aplicação de diferentes métodos estatísticos podem até aparecer dentro de um único plano de execução final, embora raramente sejam percebidas.
Como observação, o estimador de cardinalidade do SQL Server 2014 adota uma abordagem diferente para combinar as informações do histograma ajustado por filtro independente ( "alinhamento grosseiro" ), o que resulta em uma estimativa final diferente de 10,1006 linhas para esta consulta:
Este é o mesmo resultado do cálculo da questão, embora o raciocínio detalhado seja diferente (ou seja, não é baseado em uma implementação de loops aninhados assumida).