Explication détaillée de la différence et de l'utilisation des symboles # et $ dans Mabitis-javaDidacticiel-php.cn

Explication détaillée de la différence et de l'utilisation des symboles # et $ dans Mabitis

黄舟

Libérer： 2017-03-08 11:01:47

original

1751 Les gens l'ont consulté

Cet article présente principalement la différence entre les symboles # et $ dans Mabitis. Les amis dans le besoin peuvent s'y référer

1 Introduction

Mybatis utilise la configuration dans Mapper.xml pour effectuer des requêtes SQL. Il est souvent nécessaire de transmettre dynamiquement des paramètres. Par exemple, lorsque nous devons filtrer les utilisateurs en fonction de leurs noms, le sql est le suivant :

<.>

select * from user where name = "Jack";

Copier après la connexion

Dans le SQL ci-dessus, nous espérons que le paramètre "Jack" après le nom est dynamiquement variable, c'est-à-dire que les utilisateurs peuvent être interrogés en fonction de différents noms à différents moments . Utilisez le SQL suivant dans le fichier Mapper.xml pour transmettre dynamiquement le nom du paramètre :

select * from user where name = #{name};

Copier après la connexion

ou :

select * from user where name = ${name};

Copier après la connexion

2.$ et #

1.Dynamique. SQL est l'une des fonctionnalités puissantes de mybatis et une raison importante pour laquelle il est supérieur aux autres frameworks ORM. Avant que mybatis ne précompile l'instruction SQL, il analysera dynamiquement le SQL et l'analysera dans un objet BoundSql, où le SQL dynamique est également traité. Pendant la phase d'analyse SQL dynamique, #{ } et ${ } se comporteront différemment.

#{ } : analysé dans un marqueur de paramètre d'une instruction préparée JDBC.

Par exemple, l'instruction SQL suivante dans Mapper.xml :

est résolue dynamiquement en :

select * from user where name = #{name};

Copier après la connexion

Un #{ } est analysé comme un espace réservé de paramètre ?.

select * from user where name = ?;

Copier après la connexion

Et ${ } n'est qu'un pur remplacement de chaîne, le remplacement de variable sera effectué pendant l'étape d'analyse SQL dynamique.

Par exemple, le sql suivant dans Mapper.xml :

Lorsque le paramètre que nous passons est "Jack", ce qui précède sql L'analyse est la suivante :

select * from user where name = ${name};

Copier après la connexion

L'instruction SQL avant la précompilation ne contient plus de variables et est une donnée complètement constante.

select * from user where name = "Jack";

Copier après la connexion

Pour résumer, la phase de remplacement des variables ${ } se fait dans la phase d'analyse SQL dynamique, tandis que le remplacement de #{ } variables se fait dans le SGBD.

3. Utilisation

1 Lorsque #{ } peut être utilisé, utilisez #{ }

Tout d'abord, pour des raisons de performances, le même SQL précompilé peut être réutilisé. Deuxièmement, ${ } a été remplacé par des variables avant la précompilation, ce qui entraînera des problèmes d'injection SQL. Par exemple, le sql suivant :

Si notre paramètre tableName est user ; delete user --, alors après l'étape d'analyse dynamique SQL, pré - Le sql avant compilation deviendra :

select * from ${tableName} where name = #{name}

Copier après la connexion

2. Lorsque le nom de la table est utilisé comme variable, ${ }

select * from user; delete user; -- where name = ?; 
-- 之后的语句将作为注释，不起作用，因此本来的一条查询语句偷偷的包含了一个删除表数据的 SQL。

Copier après la connexion

. <🎜 doit être utilisé >

En effet, le nom de la table est une chaîne Lorsque vous utilisez un espace réservé SQL pour remplacer la chaîne, des guillemets simples '' seront inclus, ce qui provoquera des erreurs de syntaxe SQL, telles que :

Le SQL précompilé devient :

select * from #{tableName} where name = #{name};

Copier après la connexion

Supposons que le paramètre que nous transmettons soit tableName = "user", name = "Jack", puis après substitution de variable dans l'espace réservé, l'instruction sql devient :

select * from ? where name = ?;

Copier après la connexion

L'instruction sql ci-dessus existe La syntaxe est incorrecte. Le nom de la table ne peut pas contenir de guillemets simples '' (notez que les guillemets `` sont autorisés).

select * from &#39;user&#39; where name=&#39;Jack&#39;;

Copier après la connexion

4. Pré-compilation SQL

Définition : Pré-compilation SQL. fait référence au pilote de base de données qui compile l'instruction SQL avant d'envoyer l'instruction SQL et les paramètres au SGBD, de sorte que lorsque le SGBD exécute le SQL, il n'a pas besoin d'être recompilé.

2. Pourquoi la précompilation est nécessaire

JDBC utilise l'objet PreparedStatement pour résumer les instructions précompilées et utilise la précompilation. La phase de précompilation permet d'optimiser l'exécution de SQL. Dans la plupart des cas, le SQL précompilé peut être exécuté directement et le SGBD n'a pas besoin d'être à nouveau compilé. Plus le SQL est complexe, plus la complexité de la compilation est grande. L'étape de précompilation peut combiner plusieurs opérations en une seule. Les objets d'instructions préparées peuvent être réutilisés. Mettez en cache l'objet PreparedStatement généré après la précompilation d'un SQL. La prochaine fois, pour le même SQL, vous pourrez directement utiliser cet objet PreparedState mis en cache. Par défaut, mybatis précompilera tout le SQL.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!