PreparedStatements et performance

Question

Donc, je n'arrête pas d'entendre que PreparedStatements sont bonnes pour la performance.

Nous avons une application Java dans lequel on utilise la régulière "Déclaration" plus de, nous utilisons le "PreparedStatement'. Tout en essayant de se déplacer vers l'utilisation de plus PreparedStatements, je suis en train d'essayer d'obtenir une compréhension plus approfondie de la façon dont PreparedStatements travail sur le côté client et côté serveur.

Donc, si nous avons certaines des opérations CRUD et de mettre à jour un objet à plusieurs reprises dans l'application, est-il utile d'utiliser un PS? Je comprends que nous allons avoir à fermer le PS à chaque fois sinon il en résultera un curseur de fuite.

Alors, comment peut-il aider avec la performance? Le pilote est de mettre en cache le fichier de déclaration et de me donner une copie de la prochaine fois que je fais de la connexion.prepareStatement? Ou ne le serveur de base de données de l'aide?

Je comprends l'argument sur les prestations de la sécurité de PreparedStatements et j'apprécie les réponses ci-dessous qui mettent l'accent sur elle. Cependant j'ai vraiment envie de garder cette discussion a porté sur les avantages de performance de PreparedStatements.

Mise à jour: Quand je dis que la mise à jour des données, je veux dire vraiment plus, en termes de méthode au hasard d'être appelé plusieurs fois. Je comprends l'avantage dans la réponse ci-dessous qui vous demande de ré-utiliser l'instruction à l'intérieur d'une boucle.

    // some code blah blah
    update();

    // some more code blah blah 
    update();

.... 

public void update () throws SQLException{
 try{
      PreparedStatement ps = connection.prepareStatement("some sql");
      ps.setString(1, "foobar1");
      ps.setString(2, "foobar2");
      ps.execute();
 }finally {
     ps.close();

 }

}

Il n'y a aucun moyen de réutiliser le 'ps' objet java, et je comprends que la connexion réelle.prepareStatement appel est assez cher.

Qui est ce qui me ramène à la question initiale. Est-ce que "certains" sql " PreparedStatement encore être mis en cache et réutilisés sous les couvertures que je ne sais pas sur?

Je devrais aussi mentionner que nous avons le support de plusieurs bases de données.

Merci à l'avance.

Answer 1

La notion que les instructions préparées sont principalement sur la performance est quelque chose d'une idée fausse, même si c'est assez courant.

Une autre affiche a mentionné qu'il a noté une amélioration de la vitesse d'environ 20% dans Oracle et SQL Server. J'ai noté une figure similaire avec MySQL. Il s'avère que l'analyse de la requête n'est tout simplement pas une partie importante du travail. Sur un de très occupé système de base de données, il n'est également pas clair que la requête d'analyse affectera le débit global: dans l'ensemble, il va probablement juste de l'utilisation de l'UC de temps qui serait autrement ralenti tandis que les données étais de retour à partir du disque.

Donc comme l'une des raisons d'utiliser des requêtes préparées, la protection contre les attaques par injection SQL, l'emporte de loin sur l'amélioration de la performance. Et si vous n'êtes pas inquiet au sujet des attaques par injection SQL, vous devriez probablement être...

Answer 2

Déclarations préparées à l'avance permet d'améliorer les performances lors de la réutilisation de la même déclaration que vous avez préparé:

PreparedStatement ps = connection.prepare("SOME SQL");

for (Data data : dataList) {
  ps.setInt(1, data.getId());
  ps.setString(2, data.getValue();
  ps.executeUpdate();
}

ps.close();

C'est beaucoup plus rapide que la création de l'instruction dans la boucle.

Certaines plates-formes de cache déclarations préparées à l'avance, de sorte que même si vous les fermez, ils peuvent être reconstruit plus rapidement.

Cependant, même si les performances sont identiques, vous devriez toujours utiliser les requêtes préparées à prévenir l'Injection SQL. Dans mon entreprise c'est une question d'entrevue; avoir tort et que nous ne puissions pas vous embaucher.

Answer 3

Les requêtes préparées sont en effet mis en cache après leur première utilisation, c'est ce qu'ils fournissent de performance standard consolidés. Si votre état de compte ne change pas alors il est conseillé d'utiliser cette méthode. Ils sont généralement stockées dans un cache d'instruction pour modifier l'utilisation.

Plus d'informations peuvent être trouvées ici:

http://www.theserverside.com/tt/articles/article.tss?l=Prepared-Statments

et vous voudrez peut-être regarder au Printemps JDBCTemplate comme une alternative à l'utilisation de JDBC directement.

http://static.springframework.org/spring/docs/2.0.x/reference/jdbc.html

Answer 4

Analyser le code SQL n'est pas la seule chose qui se passe. Il existe une validation de l'existence des tables et des colonnes, la création d'un plan de requête, etc. Vous payez une seule fois avec un PreparedStatement.

Relier pour se protéger contre l'injection SQL est une très bonne chose, en effet. Pas suffisant, IMO. Vous devez toujours valider votre entrée avant d’atteindre la couche de persistance.

Answer 5

Pour l'anecdote: j'ai fait quelques expériences avec des préparés et dynamique des déclarations à l'aide de ODBC dans Java 1.4 il y a quelques années, avec Oracle et SQL Server back-end. J'ai trouvé que les instructions préparées pourrait être 20% plus rapide pour certaines requêtes, mais il y avait spécifiques au fournisseur de différences en ce qui concerne les requêtes qui ont été améliorées dans quelle mesure. (Cela ne devrait pas être surprenant, vraiment.)

La ligne de fond est que si vous serez de nouveau avec la même requête à plusieurs reprises, des déclarations préparées peuvent aider à améliorer les performances, mais si votre performance est assez mauvais que vous devez faire quelque chose immédiatement, ne comptez pas sur l'utilisation des requêtes préparées pour vous donner un radical coup de pouce. (20% est généralement rien à écrire sur la maison.)

Votre kilométrage peut varier, bien sûr.