2009-12-05 4 views
6

Pourquoi utilise une requête paramétrées pour insérer des données dans une table:Pourquoi utiliser une requête paramétrée pour insérer des données dans une table plus rapidement que d'ajouter les valeurs à la chaîne de requête?

string queryString = "insert into product(id, name) values (@id, @name)"; 

plus vite que les valeurs à annexant la chaîne de requête:

string queryString = "insert into product(id, name) values (" + _id + ", " + _name + ")"; 

?

Lorsque j'utilise la commande dans une boucle pour insérer des lignes de 10 Ko, la requête paramétrée est plus rapide que l'autre.

Je sais qu'une requête paramétrée a des avantages en termes de sécurité et de maintenance, et c'est la méthode d'utilisation recommandée, mais je voudrais maintenant savoir pourquoi elle est beaucoup plus rapide?

+4

Ne pas remettre en question, mais profiter, il est rare que rien finissent par être plus sûr et plus rapide! :) – Phil

+0

Quelle base de données utilisez-vous? – RickNZ

Répondre

8

En général, la partie la plus coûteuse de l'exécution d'une requête SQL est la construction du plan d'exécution - identifier les tables qui seront nécessaires, déterminer les meilleurs index (le cas échéant) à utiliser, etc. Vous pouvez considérer ceci comme "compiler" la requête si vous le souhaitez. Lorsque vous utilisez une requête paramétrée, vous pouvez la préparer une seule fois, puis simplement ajouter des valeurs cibles différentes.

Comme c'est la même opération avec des données différentes, il n'est pas nécessaire de reconstruire le plan d'exécution à chaque fois. Pour étendre la métaphore de "compilation", c'est comme ré-exécuter le même programme avec un fichier de configuration différent. Lorsque vous ajoutez les valeurs, vous les codifiez en dur dans la requête. Vous devez donc les recréer à chaque fois et vous imputer le coût de construction d'un nouveau plan d'exécution pour chaque itération. Encore une fois avec la métaphore de «compilation», c'est comme un programme C avec toute sa configuration codée en dur - changer un paramètre, et vous devez recompiler le tout.

(L'autre grand coût que vous pouvez rencontrer lorsque vous effectuez des insertions de masse est la mise à jour des index.Si votre table est indexée, vous pouvez essayer de les éteindre, de les insérer et de les rallumer être réindexé une fois au lieu d'après chaque ligne est ajoutée.)

+0

La construction du plan d'exécution est la partie la plus coûteuse de l'exécution d'une requête SQL uniquement dans certaines conditions limitées - certainement pas dans un sens général. – RickNZ

+0

Avez-vous des liens vers des documentations sur la limite de ces conditions? J'étais, je le répète, simplement en train de répéter ce que l'on m'a dit, car cela semblait plausible, mais je n'ai jamais essayé de comparer la partie de l'exécution d'une requête qui prend plus de temps, donc j'aimerais connaître les faits. (De plus, OP a dit avoir vu une réduction de l'ordre de grandeur de la version paramétrée, ce qui suggère plutôt que, dans ce cas, la préparation de la requête * était * la partie la plus coûteuse de l'opération.) –

+0

prendre une minute ou plus pour courir; Certaines requêtes peuvent prendre 24 heures +. La compilation prend normalement bien moins d'une seconde. Bien sûr, si votre requête compilée s'exécute en millisecondes, alors la compilation peut devenir une fraction significative du temps d'exécution total, mais ce n'est certainement pas vrai dans le cas général comme votre réponse l'indique. – RickNZ

3

Cela est dû au fait que la base de données met en cache les plans de requête, ce qui la rend plus rapide.

Pour le serveur Sql voir cette explication

Execution Plan Caching and Reuse

4

Selon la DB que vous utilisez, la raison habituelle est parce que la requête paramétrées ne doit être compilé une fois, et la version de requête dynamique est recompilé à chaque utilisation.

+0

Cela n'a jamais été le cas sur Oracle, et SQL Server a finalement pris en charge les plans de requête dynamiques mis en cache en utilisant 'sp_executesql' depuis v2005: http://www.sommarskog.se/dynamic_sql.html#queryplans –

+0

Mise en cache automatique du plan de requête de SQL dynamique dans SQL Server ne fonctionne qu'avec un seul paramètre (auto-paramétrage); les différences au-delà sont considérées comme faisant partie de la clé pour le cache du plan. – RickNZ

5

Simple. L'analyse et la préparation du plan d'exécution d'une requête prennent beaucoup de temps avant même que l'exécution de la requête ne commence. Lorsque vous ajoutez des paramètres en tant que texte à interroger, chaque requête est différente. DB doit donc l'analyser et préparer le plan d'exécution. Lorsque vous utilisez des paramètres, vous envoyez la même requête plusieurs fois (avec des données différentes) et DB peut simplement réutiliser le plan d'exécution d'un appel précédent.

Dans la plupart des cas, il s'agit simplement d'une comparaison de texte entre des requêtes. Par exemple, dans MS SQL Server, il suffit de changer la casse d'une lettre ou d'ajouter un espace à la fin de la requête pour forcer DB à recréer le plan d'exécution.

0

Je parie que ce ne serait pas plus rapide si vous utilisez plusieurs valeurs
Vous pouvez faire jusqu'à 1000

string queryString = "insert into product(id, name) values " + 
" (" + _id + ", " + _name + ")" + 
" , (" + _id1 + ", " + _name1 + ")" + 
" , (" + _id2 + ", " + _name2 + ")";