Étant donné que l'optimiseur ne peut pas prendre tout le temps dont il a besoin (il doit minimiser le temps d'exécution et ne pas y contribuer) pour explorer tous les plans d'exécution possibles, il est parfois interrompu.
Je me demandais si cela pouvait être annulé pour que vous puissiez donner à l'optimiseur tout le temps nécessaire (ou un certain nombre de millisecondes).
Je n'ai pas besoin de cela (atm) mais je peux imaginer un scénario où une requête complexe est exécutée dans une boucle serrée et que vous souhaitez trouver le plan optimal et le mettre en cache au préalable.
Bien sûr, si vous avez une boucle serrée, vous devez réécrire la requête pour qu'elle disparaisse, mais restez avec moi.
C'est plus une question par curiosité et aussi pour voir s'il y a parfois une différence entre une optimisation court-circuitée et une optimisation complète.
Il s'avère que vous pouvez donner plus de temps à l'optimiseur avec l'indicateur de trace 2301. Ce n'est pas exactement ce que je demandais, mais il se rapproche.
La meilleure information que j'ai trouvée à ce sujet se trouve dans les extensions de modélisation de processeur de requête dans SQL Server 2005 SP1 par Ian Jose.
Utilisez ce drapeau de trace avec précaution! Mais cela peut être utile pour trouver de meilleurs plans. Voir également:
- Articles étiquetés "niveau d'optimisation" par Grant Fritchey.
- Avant de passer à SQL Server 2008… par Brent Ozar.
- Options de réglage pour SQL Server lors de l'exécution dans des charges de travail hautes performances par le support Microsoft.
Je pensais aux requêtes avec beaucoup de jointures où l'espace de solution pour l'ordre des jointures explose de façon exponentielle. L'heuristique utilisée par SQL Server est plutôt bonne, mais je me demandais si l'optimiseur proposerait un ordre différent s'il avait plus de temps (de l'ordre de quelques secondes ou même de quelques minutes).