Dado que o otimizador não pode levar todo o tempo necessário (tem que minimizar o tempo de execução e não contribuir para isso) para explorar todos os planos de execução possíveis, às vezes ele é interrompido.
Eu queria saber se isso pode ser substituído para que você possa dar ao otimizador todo o tempo necessário (ou uma certa quantidade de milissegundos).
Não preciso disso (atm), mas posso imaginar um cenário em que uma consulta complexa é executada em um loop apertado e você deseja criar o plano ideal e armazená-lo em cache com antecedência.
Claro que você tem um loop apertado, você deve reescrever a consulta para que ela desapareça, mas tenha paciência comigo.
Esta é mais uma pergunta por curiosidade e também para ver se às vezes há diferença entre uma otimização em curto-circuito e uma completa.
Acontece que você pode dar ao otimizador mais tempo com o sinalizador de rastreamento 2301. Não é exatamente o que eu estava perguntando, mas chega perto.
A melhor informação que encontrei sobre isso está em Query Processor Modeling Extensions in SQL Server 2005 SP1 por Ian Jose.
Use este sinalizador de rastreamento com cuidado! Mas pode ser útil ao criar planos melhores. Veja também:
- Artigos marcados como "nível de otimização" por Grant Fritchey.
- Antes de atualizar para o SQL Server 2008… por Brent Ozar.
- Opções de ajuste para SQL Server ao executar em cargas de trabalho de alto desempenho pelo suporte da Microsoft.
Eu estava pensando em consultas com muitas junções onde o espaço de solução para ordem de junção explode exponencialmente. As heurísticas que o SQL Server usa são muito boas, mas eu queria saber se o otimizador proporia uma ordem diferente se tivesse mais tempo (no intervalo de segundos ou até minutos).
Ao lado do sinalizador de rastreamento 2301, há 8780, que realmente faz o otimizador 'trabalhar mais', pois apenas dá mais tempo (não ilimitado, conforme descrito em detalhes aqui (russo) e menos detalhado aqui ) para fazer seu trabalho.
Descrição detalhada em inglês do autor original do artigo russo. que inclui o próprio aviso do autor:
Combinar os dois e aplicá-los (muito seletivamente por meio da dica de consulta OPTION (QUERYTRACEON 2301, QUERYTRACEON 8780) a uma consulta de TVFs embutidos de 4 níveis (em que apenas o da parte inferior faria qualquer trabalho real e os níveis superiores correlacionariam os resultados via subconsultas EXISTS) resultou em um bom MERGE JOIN e vários LAZY SPOOLs que reduziram o tempo de execução pela metade.
Não, você não pode.
Você pode tornar suas consultas "amigáveis ao otimizador" entendendo como ele funciona (besta complexa, não é necessário conhecê-lo de dentro para fora). Sugiro que, se você tiver algo tão crítico quanto ao tempo, corrija a consulta em vez de alterar a forma como o SQL Server opera.
Por exemplo, você gostaria de saber quando uma consulta começa a ser dimensionada com menos eficiência do que O(n) conforme o volume de dados + a distribuição de dados muda: dar mais tempo ao otimizador não adiciona nenhum valor aqui.