Recentemente, me deparei com um problema em que tSQLt
os testes demoravam muito para serem executados.
O procedimento em teste estava fazendo uma junção de 38 tabelas (!) (com 37 tabelas falsificadas e um parâmetro com valor de tabela).
Apenas duas das tabelas falsificadas e o TVP tiveram alguma linha inserida
Os tempos de compilação eram extremamente lentos.
Sinalizador de rastreamento 8675 mostrado
End of simplification, time: 0.002 net: 0.002 total: 0 net: 0.002
end exploration, tasks: 549 no total cost time: 0.013 net: 0.013 total: 0 net: 0.015
end search(0), cost: 13372.9 tasks: 3517 time: 0.012 net: 0.012 total: 0 net: 0.028
end exploration, tasks: 3983 Cost = 13372.9 time: 0 net: 0 total: 0 net: 0.028
end search(1), cost: 6706.79 tasks: 10187 time: 0.024 net: 0.024 total: 0 net: 0.052
end exploration, tasks: 10188 Cost = 6706.79 time: 0 net: 0 total: 0 net: 0.052
end search(1), cost: 6706.79 tasks: 61768 time: 0.165 net: 0.165 total: 0 net: 0.218
*** Optimizer time out abort at task 614400 ***
end search(2), cost: 6706.79 tasks: 614400 time: 12.539 net: 12.539 total: 12 net: 12.758
*** Optimizer time out abort at task 614400 ***
End of post optimization rewrite, time: 0.001 net: 0.001 total: 12 net: 12.759
End of query plan compilation, time: 0.003 net: 0.003 total: 12 net: 12.762
SQL Server parse and compile time:
CPU time = 12735 ms, elapsed time = 12770 ms.
Parece que as linhas estimadas crescem exponencialmente para cada junção entre tabelas vazias até que, no final, a contagem estimada de linhas foi de 135.601.000 e a consulta teve um custo estimado enorme justificando um tempo de compilação mais longo.
Havia uma tabela específica envolvida em muitas dessas junções e a inserção de uma única linha nessa tabela foi suficiente para parar essa explosão nas junções em que a tabela estava envolvida (a saída do estimador de cardinalidade indica que agora está usando o histograma de estatísticas dessa tabela )
O comportamento original parece estranho para mim. O SQL Server sabe que a tabela à qual está se juntando está vazia e o white paper do plano de cache indica que a inserção de qualquer linha em uma tabela vazia fará com que o limite de recompilação seja atingido, então há algum bom motivo para isso?
Repro mostrando o crescimento estimado da contagem de linhas (embora sem longos tempos de compilação)
CREATE TABLE T1(C1 INT);
INSERT INTO T1 VALUES (1),(2),(3),(4),(5),(6),(7),(8),(9);
CREATE TABLE T2(C1 INT, C2 VARCHAR(MAX));
SELECT *
FROM T1 LEFT OUTER JOIN T2 ON T1.C1 = T2.C1
LEFT OUTER JOIN T2 T3 ON T3.C1 = T2.C1
LEFT OUTER JOIN T2 T4 ON T4.C1 = T2.C1
LEFT OUTER JOIN T2 T5 ON T5.C1 = T2.C1
LEFT OUTER JOIN T2 T6 ON T6.C1 = T2.C1
LEFT OUTER JOIN T2 T7 ON T7.C1 = T2.C1
LEFT OUTER JOIN T2 T8 ON T8.C1 = T2.C1
LEFT OUTER JOIN T2 T9 ON T9.C1 = T2.C1
LEFT OUTER JOIN T2 T10 ON T10.C1 = T2.C1
LEFT OUTER JOIN T2 T11 ON T11.C1 = T2.C1
LEFT OUTER JOIN T2 T12 ON T12.C1 = T2.C1
LEFT OUTER JOIN T2 T13 ON T13.C1 = T2.C1
LEFT OUTER JOIN T2 T14 ON T14.C1 = T2.C1
LEFT OUTER JOIN T2 T15 ON T15.C1 = T2.C1
LEFT OUTER JOIN T2 T16 ON T16.C1 = T2.C1
LEFT OUTER JOIN T2 T17 ON T17.C1 = T2.C1
LEFT OUTER JOIN T2 T18 ON T18.C1 = T2.C1
LEFT OUTER JOIN T2 T19 ON T19.C1 = T2.C1
LEFT OUTER JOIN T2 T20 ON T20.C1 = T2.C1
LEFT OUTER JOIN T2 T21 ON T21.C1 = T2.C1
LEFT OUTER JOIN T2 T22 ON T22.C1 = T2.C1
LEFT OUTER JOIN T2 T23 ON T23.C1 = T2.C1
LEFT OUTER JOIN T2 T24 ON T24.C1 = T2.C1
LEFT OUTER JOIN T2 T25 ON T25.C1 = T2.C1
LEFT OUTER JOIN T2 T26 ON T26.C1 = T2.C1
LEFT OUTER JOIN T2 T27 ON T27.C1 = T2.C1
LEFT OUTER JOIN T2 T28 ON T28.C1 = T2.C1
LEFT OUTER JOIN T2 T29 ON T29.C1 = T2.C1
LEFT OUTER JOIN T2 T30 ON T30.C1 = T2.C1
LEFT OUTER JOIN T2 T31 ON T31.C1 = T2.C1
LEFT OUTER JOIN T2 T32 ON T32.C1 = T2.C1
LEFT OUTER JOIN T2 T33 ON T33.C1 = T2.C1
LEFT OUTER JOIN T2 T34 ON T34.C1 = T2.C1
LEFT OUTER JOIN T2 T35 ON T35.C1 = T2.C1
LEFT OUTER JOIN T2 T36 ON T36.C1 = T2.C1
LEFT OUTER JOIN T2 T37 ON T37.C1 = T2.C1
LEFT OUTER JOIN T2 T38 ON T38.C1 = T2.C1
LEFT OUTER JOIN T2 T39 ON T39.C1 = T2.C1