Symptômes
Lorsque vous remplissez une variable de table avec de nombreuses lignes et que vous la Rejoignez avec d’autres tables, l’optimiseur de requête risque de choisir un plan de requête inefficace, ce qui pourrait entraîner une lenteur des performances de requête.
Résolution
Après avoir appliqué ce correctif, vous pouvez activer l’indicateur de suivi 2453 pour permettre à une variable de table d’être recompilée en cas de modification d’un nombre suffisant de lignes. L’optimiseur de requête peut ainsi choisir une offre plus efficace. Le problème a été résolu dans la mise à jour cumulative ou/ou les service packs suivants pour SQL Server.
Mise à jour cumulative 3 pour SQL Server 2014 /en-us/help/2984923
Chaque nouvelle mise à jour cumulative pour SQL Server contient tous les correctifs et les correctifs de sécurité inclus dans la mise à jour cumulative précédente. Consultez les dernières mises à jour cumulatives pour SQL Server :
Les Service Packs sont cumulatifs. Chaque nouvelle version contient tous les correctifs fournis dans les Service Packs précédents et tous les nouveaux correctifs. Nous vous recommandons d’appliquer le dernier Service Pack et la dernière mise à jour cumulative de ce Service Pack. Il n'est donc pas nécessaire d'installer la version antérieure d'un Service Pack avant d'installer la dernière version disponible. Utilisez le tableau 1 de l’article suivant pour trouver plus d’informations sur le dernier Service Pack et la dernière mise à jour cumulative :
Déterminer le niveau de version, d’édition et de mise à jour de SQL Server et ses composants
Informations supplémentaires
Lorsque vous utilisez une variable de table dans un lot ou une procédure, la requête est compilée et optimisée pour l’état vide initial de la variable de table. Si cette variable de tableau contient plusieurs lignes au moment de l’exécution, le plan de requête déjà compilé peut ne plus être optimal. Par exemple, la requête peut rejoindre une variable de table avec une boucle imbriquée, car elle est généralement plus efficace pour un petit nombre de lignes. Ce plan de requête peut être inefficace si la variable de table comporte des millions de lignes. Un choix de hachage est un meilleur choix dans une condition. Pour obtenir un nouveau plan de requête, il doit être recompilé. En revanche, contrairement aux autres tables utilisateur ou temporaires, la modification du nombre de lignes dans une variable de table ne déclenche pas la recompilation de la requête. En règle générale, vous pouvez contourner le problème avec l’OPTION (RECOMPILE) qui dispose de ses propres frais. L’indicateur de suivi 2453 permet de recompiler une requête sans OPTION (recompilez). Cet indicateur de suivi est différent de l’OPTION (RECOMPILE) dans deux principaux aspects. (1) elle utilise le même seuil de nombre de lignes que d’autres tables. La requête n’a pas besoin d’être compilée pour chaque exécution, contrairement à l’OPTION (RECOMPILE). Il déclenche une recompilation uniquement lorsque la modification du nombre de lignes dépasse le seuil prédéfini. (2) OPTION (RECOMPILE) force la requête à lire les paramètres et à optimiser la requête. Cet indicateur de suivi ne force pas la lecture de paramètre.Remarque cet indicateur de suivi doit être activé lors de l’exécution. Vous ne pouvez pas utiliser cet indicateur de suivi avec QUERYTRACEON. Cet indicateur de suivi doit être utilisé avec précaution, car il peut augmenter le nombre de recharges de requête qui peuvent coûter plus d’argent qu’une amélioration de l’optimisation des requêtes.
Statut
Microsoft a confirmé l’existence de ce problème dans les produits Microsoft répertoriés dans la section « S’applique à ».