Exécution préparée

S’applique à :SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse AnalyticsAnalytics Platform System (PDW)

L’API ODBC définit l’exécution préparée comme un moyen de réduire la surcharge d’analyse et de compilation associée à l’exécution répétée d’une instruction Transact-SQL. L'application génère une chaîne de caractères contenant une instruction SQL, puis l'exécute en deux étapes. Il appelle sqlPrepare Function une fois pour que l’instruction soit analysée et compilée dans un plan d’exécution par le moteur de base de données. Il appelle ensuite SQLExecute pour chaque exécution du plan d’exécution préparé. Cela permet de réduire la charge d'analyse et de compilation pour chaque exécution. L'exécution préparée est couramment utilisée par les applications pour exécuter de manière répétée la même instruction SQL paramétrable.

Avec la plupart des bases de données, l'exécution préparée est plus rapide que l'exécution directe pour les instructions qui sont exécutées plus de trois ou quatre fois principalement du fait que l'instruction est compilée une seule fois, alors que les instructions exécutées directement sont compilées chaque fois qu'elles sont exécutées. L'exécution préparée peut également permettre de réduire le trafic réseau car le pilote peut envoyer un identificateur de plan d'exécution et les valeurs de paramètre, plutôt qu'une instruction SQL entière, à la source de données chaque fois que l'instruction est exécutée.

SQL Server réduit la différence de performances entre l’exécution directe et l’exécution préparée grâce à des algorithmes améliorés pour la détection et la réutilisation des plans d’exécution à partir de SQLExecDirect. Les avantages de l'exécution préparée en termes de performances s'étendent ainsi dans une certaine mesure aux instructions exécutées directement. Pour plus d’informations, consultez Exécution directe.

SQL Server fournit également une prise en charge native pour l’exécution préparée. Un plan d’exécution est basé sur SQLPrepare et exécuté ultérieurement lorsque SQLExecute est appelé. Étant donné que SQL Server n’est pas nécessaire pour créer des procédures stockées temporaires sur SQLPrepare, il n’y a pas de surcharge supplémentaire sur les tables système dans tempdb.

Pour des raisons de performances, la préparation de l’instruction est différée jusqu’à ce que SQLExecute soit appelé ou qu’une opération de métapropriété (telle que SQLDescribeCol ou SQLDescribeParam dans ODBC) soit effectuée. Il s'agit du comportement par défaut. Toute erreur dans l'instruction en cours de préparée reste inconnue tant que l'instruction n'a pas été exécutée ou qu'une opération de métapropriété n'a pas été effectuée. La définition de l’attribut d’instruction SQL Server Native Client spécifique au pilote ODBC SQL_SOPT_SS_DEFER_PREPARE sur SQL_DP_OFF peut désactiver ce comportement par défaut.

En cas de préparation différée, l’appel de SQLDescribeCol ou SQLDescribeParam avant d’appeler SQLExecute génère un aller-retour supplémentaire vers le serveur. Sur SQLDescribeCol, le pilote supprime la clause WHERE de la requête et l’envoie au serveur avec SET FMTONLY ON pour obtenir la description des colonnes du premier jeu de résultats retourné par la requête. Sur SQLDescribeParam, le pilote appelle le serveur pour obtenir une description des expressions ou des colonnes référencées par les marqueurs de paramètre dans la requête. Cette méthode présente également certaines restrictions, comme le fait qu'elle ne permette pas de résoudre les paramètres dans les sous-requêtes.

L’utilisation excessive de SQLPrepare avec le pilote ODBC SQL Server Native Client dégrade les performances, en particulier lorsqu’il est connecté à des versions antérieures de SQL Server. L'exécution préparée ne doit pas être utilisée pour les instructions exécutées une seule fois. L'exécution préparée est plus lente que l'exécution directe en cas d'exécution unique d'une instruction car elle requiert un aller-retour réseau supplémentaire entre le client et le serveur. Sur les versions antérieures de SQL Server il génère également une procédure stockée temporaire.

Les instructions préparées ne peuvent pas être utilisées pour la création d'objets temporaires dans SQL Server.

Certaines premières applications ODBC utilisaient SQLPrepare chaque fois que SQLBindParameter a été utilisé. SQLBindParameter ne nécessite pas l’utilisation de SQLPrepare, il peut être utilisé avec SQLExecDirect. Par exemple, utilisez SQLExecDirect avec SQLBindParameter pour récupérer le code de retour ou les paramètres de sortie d’une procédure stockée exécutée une seule fois. N’utilisez pas SQLPrepare avec SQLBindParameter , sauf si la même instruction est exécutée plusieurs fois.

Voir aussi

Exécution d’instructions (ODBC)