Testei no SQL Server 2014 com o CE herdado e também não recebi 9% como estimativa de cardinalidade. Como não encontrei nada preciso on-line, fiz alguns testes e encontrei um modelo que se encaixa em todos os casos de teste que experimentei, mas não tenho certeza de que esteja completo.
No modelo que encontrei, a estimativa é derivada do número de linhas na tabela, do comprimento médio da chave das estatísticas da coluna filtrada e, às vezes, do comprimento do tipo de dados da coluna filtrada. Existem duas fórmulas diferentes usadas para a estimativa.
Se FLOOR (comprimento médio da chave) = 0, a fórmula de estimativa ignora as estatísticas da coluna e cria uma estimativa com base no comprimento do tipo de dados. Eu testei apenas com VARCHAR (N), então é possível que exista uma fórmula diferente para o NVARCHAR (N). Aqui está a fórmula para VARCHAR (N):
(estimativa de linha) = (linhas na tabela) * (-0,004869 + 0,032649 * log10 (comprimento do tipo de dados))
Esse ajuste é muito bom, mas não é perfeitamente preciso:
O eixo x é o comprimento do tipo de dados e o eixo y é o número de linhas estimadas para uma tabela com 1 milhão de linhas.
O otimizador de consulta usaria essa fórmula se você não tivesse estatísticas na coluna ou se a coluna tiver valores NULL suficientes para conduzir o comprimento médio da chave abaixo de 1.
Por exemplo, suponha que você tivesse uma tabela com 150 mil linhas com filtragem em um VARCHAR (50) e nenhuma estatística de coluna. A previsão de estimativa de linha é:
150000 * (-0,004869 + 0,032649 * log10 (50)) = 7590,1 linhas
SQL para testá-lo:
CREATE TABLE X_CE_LIKE_TEST_1 (
STRING VARCHAR(50)
);
CREATE STATISTICS X_STAT_CE_LIKE_TEST_1 ON X_CE_LIKE_TEST_1 (STRING) WITH NORECOMPUTE;
WITH
L0 AS (SELECT 1 AS c UNION ALL SELECT 1),
L1 AS (SELECT 1 AS c FROM L0 A CROSS JOIN L0 B),
L2 AS (SELECT 1 AS c FROM L1 A CROSS JOIN L1 B),
L3 AS (SELECT 1 AS c FROM L2 A CROSS JOIN L2 B),
L4 AS (SELECT 1 AS c FROM L3 A CROSS JOIN L3 B CROSS JOIN L2 C),
NUMS AS (SELECT ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) AS NUM FROM L4)
INSERT INTO X_CE_LIKE_TEST_1 WITH (TABLOCK) (STRING)
SELECT TOP (150000) 'ZZZZZ'
FROM NUMS
ORDER BY NUM;
DECLARE @LastName VARCHAR(15) = 'BA%'
SELECT * FROM X_CE_LIKE_TEST_1
WHERE STRING LIKE @LastName;
O SQL Server fornece uma contagem estimada de linhas de 7242,47, que é quase fechada.
Se FLOOR (comprimento médio da chave)> = 1, uma fórmula diferente será usada com base no valor de FLOOR (comprimento médio da chave). Aqui está uma tabela de alguns dos valores que eu tentei:
1 1.5%
2 1.5%
3 1.64792%
4 2.07944%
5 2.41416%
6 2.68744%
7 2.91887%
8 3.11916%
9 3.29584%
10 3.45388%
Se FLOOR (comprimento médio da chave) <6, use a tabela acima. Caso contrário, use a seguinte equação:
(estimativa de linha) = (linhas da tabela) * (-0,003381 + 0,034539 * log10 (PISO (comprimento médio da chave)))
Este tem um ajuste melhor que o outro, mas ainda não é perfeitamente preciso.
O eixo x é o comprimento médio da chave e o eixo y é o número estimado de linhas para uma tabela com 1 milhão de linhas.
Para dar outro exemplo, suponha que você tenha uma tabela com 10 mil linhas com um comprimento médio de chave de 5,5 para as estatísticas na coluna filtrada. A estimativa de linha seria:
10000 * 0,241416 = 241,416 linhas.
SQL para testá-lo:
CREATE TABLE X_CE_LIKE_TEST_2 (
STRING VARCHAR(50)
);
WITH
L0 AS (SELECT 1 AS c UNION ALL SELECT 1),
L1 AS (SELECT 1 AS c FROM L0 A CROSS JOIN L0 B),
L2 AS (SELECT 1 AS c FROM L1 A CROSS JOIN L1 B),
L3 AS (SELECT 1 AS c FROM L2 A CROSS JOIN L2 B),
L4 AS (SELECT 1 AS c FROM L3 A CROSS JOIN L3 B CROSS JOIN L2 C),
NUMS AS (SELECT ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) AS NUM FROM L4)
INSERT INTO X_CE_LIKE_TEST_2 WITH (TABLOCK) (STRING)
SELECT TOP (10000)
CASE
WHEN NUM % 2 = 1 THEN REPLICATE('Z', 5)
ELSE REPLICATE('Z', 6)
END
FROM NUMS
ORDER BY NUM;
CREATE STATISTICS X_STAT_CE_LIKE_TEST_2 ON X_CE_LIKE_TEST_2 (STRING)
WITH NORECOMPUTE, FULLSCAN;
DECLARE @LastName VARCHAR(15) = 'BA%'
SELECT * FROM X_CE_LIKE_TEST_2
WHERE STRING LIKE @LastName;
A estimativa de linha é 241,416, que corresponde ao que você tem na pergunta. Ocorreria algum erro se eu usasse um valor que não esteja na tabela.
Os modelos aqui não são perfeitos, mas acho que ilustram muito bem o comportamento geral.