Heh... desculpe a demora em responder a um post antigo. E, sim, eu tive que responder porque a resposta mais popular (na época, a resposta CTE recursiva com o link para 14 métodos diferentes) neste tópico é, ummm... desempenho desafiado na melhor das hipóteses.
Primeiro, o artigo com as 14 soluções diferentes é bom para ver os diferentes métodos de criação de uma tabela Numbers/Tally em tempo real, mas como apontado no artigo e no tópico citado, há um muito citação importante...
"Sugestões sobre eficiência e desempenho são muitas vezes subjetivas. Independentemente de como uma consulta está sendo usada, a implementação física determina a eficiência de uma consulta. Portanto, em vez de confiar em diretrizes tendenciosas, é imperativo que você teste a consulta e determine qual delas tem melhor desempenho."
Ironicamente, o próprio artigo contém muitas declarações subjetivas e "diretrizes tendenciosas", como "uma CTE recursiva pode gerar uma lista de números com bastante eficiência " e "Este é um método eficiente de usar o loop WHILE de uma postagem de grupo de notícias de Itzik Ben-Gen" (que eu tenho certeza que ele postou apenas para fins de comparação). Vamos lá pessoal... Apenas mencionar o bom nome de Itzik pode levar algum pobre coitado a realmente usar esse método horrível. O autor deve praticar o que prega e deve fazer um pequeno teste de desempenho antes de fazer declarações tão ridiculamente incorretas especialmente diante de qualquer escalabilidade.
Com o pensamento de realmente fazer alguns testes antes de fazer qualquer afirmação subjetiva sobre o que qualquer código faz ou o que alguém "gosta", aqui está um código com o qual você pode fazer seus próprios testes. Configure o profiler para o SPID do qual você está executando o teste e verifique por si mesmo...
--===== Test for 1000000 rows ==================================
GO
--===== Traditional RECURSIVE CTE method
WITH Tally (N) AS
(
SELECT 1 UNION ALL
SELECT 1 + N FROM Tally WHERE N < 1000000
)
SELECT N
INTO #Tally1
FROM Tally
OPTION (MAXRECURSION 0);
GO
--===== Traditional WHILE LOOP method
CREATE TABLE #Tally2 (N INT);
SET NOCOUNT ON;
DECLARE @Index INT;
SET @Index = 1;
WHILE @Index <= 1000000
BEGIN
INSERT #Tally2 (N)
VALUES (@Index);
SET @Index = @Index + 1;
END;
GO
--===== Traditional CROSS JOIN table method
SELECT TOP (1000000)
ROW_NUMBER() OVER (ORDER BY (SELECT 1)) AS N
INTO #Tally3
FROM Master.sys.All_Columns ac1
CROSS JOIN Master.sys.ALL_Columns ac2;
GO
--===== Itzik's CROSS JOINED CTE method
WITH E00(N) AS (SELECT 1 UNION ALL SELECT 1),
E02(N) AS (SELECT 1 FROM E00 a, E00 b),
E04(N) AS (SELECT 1 FROM E02 a, E02 b),
E08(N) AS (SELECT 1 FROM E04 a, E04 b),
E16(N) AS (SELECT 1 FROM E08 a, E08 b),
E32(N) AS (SELECT 1 FROM E16 a, E16 b),
cteTally(N) AS (SELECT ROW_NUMBER() OVER (ORDER BY N) FROM E32)
SELECT N
INTO #Tally4
FROM cteTally
WHERE N <= 1000000;
GO
--===== Housekeeping
DROP TABLE #Tally1, #Tally2, #Tally3, #Tally4;
GO
Enquanto estamos nisso, aqui estão os números que recebo do SQL Profiler para os valores de 100, 1000, 10000, 100000 e 1000000...
SPID TextData Dur(ms) CPU Reads Writes
---- ---------------------------------------- ------- ----- ------- ------
51 --===== Test for 100 rows ============== 8 0 0 0
51 --===== Traditional RECURSIVE CTE method 16 0 868 0
51 --===== Traditional WHILE LOOP method CR 73 16 175 2
51 --===== Traditional CROSS JOIN table met 11 0 80 0
51 --===== Itzik's CROSS JOINED CTE method 6 0 63 0
51 --===== Housekeeping DROP TABLE #Tally 35 31 401 0
51 --===== Test for 1000 rows ============= 0 0 0 0
51 --===== Traditional RECURSIVE CTE method 47 47 8074 0
51 --===== Traditional WHILE LOOP method CR 80 78 1085 0
51 --===== Traditional CROSS JOIN table met 5 0 98 0
51 --===== Itzik's CROSS JOINED CTE method 2 0 83 0
51 --===== Housekeeping DROP TABLE #Tally 6 15 426 0
51 --===== Test for 10000 rows ============ 0 0 0 0
51 --===== Traditional RECURSIVE CTE method 434 344 80230 10
51 --===== Traditional WHILE LOOP method CR 671 563 10240 9
51 --===== Traditional CROSS JOIN table met 25 31 302 15
51 --===== Itzik's CROSS JOINED CTE method 24 0 192 15
51 --===== Housekeeping DROP TABLE #Tally 7 15 531 0
51 --===== Test for 100000 rows =========== 0 0 0 0
51 --===== Traditional RECURSIVE CTE method 4143 3813 800260 154
51 --===== Traditional WHILE LOOP method CR 5820 5547 101380 161
51 --===== Traditional CROSS JOIN table met 160 140 479 211
51 --===== Itzik's CROSS JOINED CTE method 153 141 276 204
51 --===== Housekeeping DROP TABLE #Tally 10 15 761 0
51 --===== Test for 1000000 rows ========== 0 0 0 0
51 --===== Traditional RECURSIVE CTE method 41349 37437 8001048 1601
51 --===== Traditional WHILE LOOP method CR 59138 56141 1012785 1682
51 --===== Traditional CROSS JOIN table met 1224 1219 2429 2101
51 --===== Itzik's CROSS JOINED CTE method 1448 1328 1217 2095
51 --===== Housekeeping DROP TABLE #Tally 8 0 415 0
Como você pode ver, o método Recursive CTE é o segundo pior apenas para o While Loop para Duração e CPU e tem 8 vezes a pressão de memória na forma de leituras lógicas do que o While Loop . É RBAR em esteróides e deve ser evitado, a todo custo, para quaisquer cálculos de linha única, assim como um While Loop deve ser evitado. Há lugares onde a recursão é bastante valiosa, mas este NÃO É um deles .
Como uma barra lateral, o Sr. Denny está absolutamente certo... uma tabela de Números ou Tally permanente de tamanho correto é o caminho a percorrer para a maioria das coisas. O que significa dimensionado corretamente? Bem, a maioria das pessoas usa uma tabela Tally para gerar datas ou fazer divisões em VARCHAR(8000). Se você criar uma tabela Tally de 11.000 linhas com o índice clusterizado correto em "N", você terá linhas suficientes para criar mais de 30 anos de datas (eu trabalho bastante com hipotecas, então 30 anos é um número chave para mim ) e certamente o suficiente para lidar com uma divisão VARCHAR(8000). Por que o "dimensionamento certo" é tão importante? Se a tabela Tally for muito usada, ela cabe facilmente no cache, o que a torna incrivelmente rápida sem muita pressão na memória.
Por último, mas não menos importante, todos sabem que, se você criar uma tabela Tally permanente, não importa muito qual método você usa para construí-la porque 1) ela será feita apenas uma vez e 2) se for algo como 11.000 linhas tabela, todos os métodos serão executados "bom o suficiente". Então, por que toda a indiscrição da minha parte sobre qual método usar???
A resposta é que algum pobre rapaz/garota que não sabe nada melhor e só precisa fazer seu trabalho pode ver algo como o método CTE Recursivo e decidir usá-lo para algo muito maior e usado com muito mais frequência do que construir uma tabela Tally permanente e estou tentando proteger essas pessoas, os servidores em que seus códigos são executados e a empresa proprietária dos dados nesses servidores . Sim... é um grande negócio. Deveria ser para todos os outros também. Ensine a maneira certa de fazer as coisas em vez de "bom o suficiente". Faça alguns testes antes de postar ou usar algo de um post ou livro... a vida que você salva pode, de fato, ser sua, especialmente se você acha que um CTE recursivo é o caminho a seguir para algo assim.;-)
Obrigado por ouvir...
