2009-09-01 1 views
12

Ho letto molto sulle dichiarazioni preparate e in tutto ciò che ho letto, nessuno parla degli aspetti negativi del loro utilizzo. Pertanto, mi chiedo se ci siano dei "ci sono dei draghi" che le persone tendono a trascurare?Ci sono degli svantaggi nell'usare le istruzioni preparate?

+0

Tutto nell'IT ha aspetti negativi, è sufficiente verificare se valgono davvero la pena di preoccuparsi del problema specifico. :) Questo collegamento in SO http://stackoverflow.com/questions/535464/when-not-to-use-prepared-statements/537834 contiene alcuni esempi sugli svantaggi delle dichiarazioni preparate. – GmonC

risposta

8

L'istruzione preparata è solo un'istruzione analizzata e precompilata SQL che attende solo l'esecuzione delle variabili associate.

Ogni istruzione eseguita viene preparata prima o poi (deve essere analizzata, ottimizzata, compilata e quindi eseguita).

Una dichiarazione preparata riutilizza solo i risultati di analisi, ottimizzazione e compilazione.

Di solito i sistemi di database utilizzano un qualche tipo di ottimizzazione per risparmiare un po 'di tempo sulla preparazione delle query anche se non si utilizzano le query preparate da soli.

Oracle, ad esempio, quando l'analisi di una query controlla prima la cache della libreria e se la stessa istruzione era già stata analizzata, utilizza invece il piano di esecuzione memorizzato nella cache.

+3

Penso che a questa risposta manchi un problema chiave con le dichiarazioni preparate, ad es. che il piano di query è ottimizzato in base alle statistiche dei dati presenti al momento della preparazione della query e potrebbe non essere ottimale in futuro, quando viene eseguita la query. Quindi questo è un aspetto negativo di una dichiarazione preparata. – egbokul

+0

Alcuni articoli che menzionano un simile aspetto negativo: https://medium.com/@devinburnette/be-prepared-7768d1a111e1 --- e --- https: //www.vividcortex.com/blog/2014/11/19/analysis-prepared-statement-performance-with-vividcortex/ – MarsAndBack

3

Se si utilizza un'istruzione solo una volta o se si generano automaticamente istruzioni SQL dinamiche (e si evitano correttamente tutte le informazioni o si è certi che i parametri abbiano solo caratteri sicuri), non si devono utilizzare istruzioni preparate.

+3

Naturalmente, questo è estremamente raro. Trovo molto più facile avere solo le istruzioni preparate sul lato server per l'igienizzazione dell'input. – Powerlord

1

L'unico lato negativo che posso pensare è che occupano memoria sul server. Non è molto, ma ci sono probabilmente alcuni casi limite in cui sarebbe un problema, ma mi viene difficile pensare a nessuno.

3

C'è un altro piccolo problema con istruzioni preparate vs sql dinamico, e cioè che può essere più difficile eseguirne il debug. Con sql dinamico, puoi sempre scrivere una query di problema in un file di log ed eseguirlo direttamente sul server esattamente come lo vede il tuo programma. Con le istruzioni preparate può essere necessario un po 'più di lavoro per testare la query con uno specifico set di parametri determinati dai dati di crash. Ma non molto di più, e la sicurezza extra giustifica sicuramente il costo.

2

in alcune situazioni, il motore di database potrebbe presentare un piano di query inferiore quando si utilizza un'istruzione preparata (perché non può fare le assunzioni corrette senza avere i valori di bind effettivi per una ricerca).

vedere ad es. la sezione "Note" alla

http://www.postgresql.org/docs/current/static/sql-prepare.html

quindi potrebbe essere la pena di testare le vostre domande con e senza redazione dei documenti per scoprire che è più veloce. idealmente, deciderete in base all'istruzione se utilizzare o meno istruzioni preparate, sebbene non tutte le ORM vi consentano di farlo.

+2

Ho trovato che lo schema migliore è utilizzare un approccio tutto o niente per le istruzioni preparate. Il DBMS è più intelligente della maggior parte di noi e può calcolare il miglior piano la maggior parte del tempo. Inoltre sono certo che tu sappia che diversi DBMS avranno strategie di piani di query differenti, quindi il link non dovrebbe essere usato come un catch-all per le dichiarazioni preparate. Se si utilizza il DBMS per il lavoro sul Web, il modo più semplice e rapido per difendersi dagli attacchi SQL injection è di utilizzare sempre istruzioni preparate. – bakoyaro