Le istruzioni preparate consentono di eseguire comandi SQL ripetitivi che possono differire solo per i valori dei parametri, ad esempio.
Non sono destinati a vivere "a lungo" poiché un'istruzione preparata potrebbe (lo fanno se chiamata da una transazione) riservare una connessione al database attiva ("lunga" significa quando non vengono utilizzati; va benissimo eseguire ripetutamente un'istruzione preparata molti volte anche se questo richiederà molto tempo). Una connessione è una risorsa costosa e dovrebbe essere mantenuta solo per il tempo necessario. Semplicemente creando una serie di istruzioni preparate e non chiudendole, potresti esaurire le connessioni attive / consentite e quindi bloccare ulteriori comunicazioni con il server db.
Usa un'istruzione preparata se vuoi eseguire lo stesso insert , update o select istruzione con parametri diversi più volte in una richiesta (HTTP). Non utilizzare l'istruzione preparata per sopravvivere alle richieste (HTTP).
In alcune implementazioni di driver e server di database le istruzioni preparate possono anche coinvolgere risorse allocate sul server DB stesso (non nell'applicazione Go). Ad esempio, un'istruzione preparata può essere precompilata sul server DB e il server potrebbe preparare un piano di esecuzione della query, allocare determinate risorse come memoria per esso. Questi possono essere riservati in modo permanente fino alla chiusura dell'estratto conto preparato.
C'è un articolo (pubblicato da Myles McDonnell nei commenti qui sotto) che approfondisce i dettagli di implementazione di Dichiarazioni preparate in Vai. Si afferma che se le istruzioni preparate non vengono create dalle transazioni, rilasciano la connessione al pool di connessioni, ma quando necessario cercano di riutilizzare la stessa su cui sono state preparate (perché se il server db aiuta / svolge anche un ruolo attivo nella dichiarazione preparata, è vincolato alla connessione lato server). In caso contrario, si ripreparano su una nuova connessione (causando un sovraccarico di prestazioni indesiderato).
Tutto sommato, quello che descrivi è un modello funzionante e se hai un basso numero di istruzioni preparate che sono necessarie/eseguite in molte richieste successive, possono significare tempi di risposta più brevi. Ma significa anche che d'altra parte, a lungo termine, potrebbero comportare che tutte le tue dichiarazioni preparate saranno preparate su tutte le connessioni del pool. Decidi se questo è accettabile nel tuo caso.
In generale questo dovrebbe essere evitato (e l'istruzione preparata deve essere chiusa prima della fine della richiesta HTTP), ma se ne hai solo alcuni e ne hai bisogno in molte richieste che si susseguono, potresti spostarli fuori dall'ambito della richiesta .
