As instruções preparadas são para que você possa executar comandos SQL repetitivos que podem diferir apenas nos valores dos parâmetros, por exemplo.

Eles não são feitos para durar "longo" como uma instrução preparada pode (eles fazem se chamados de uma transação) reservar uma conexão de banco de dados ativa ("longo" significa quando eles não são usados; é perfeitamente normal executar repetidamente uma instrução preparada por muitos vezes, mesmo que isso demore muito). Uma conexão é um recurso caro e só deve ser mantida enquanto for necessário. Apenas criando um monte de instruções preparadas e não as fechando, você pode ficar sem conexões ativas / permitidas e bloquear mais comunicação com o servidor db.

Use uma instrução preparada se quiser executar o mesmo insert , update ou select instrução com parâmetros diferentes várias vezes em uma solicitação (HTTP). Não use a instrução preparada para sobreviver a solicitações (HTTP).

Em certas implementações de driver e servidores de banco de dados, instruções preparadas também podem envolver recursos alocados no próprio servidor de banco de dados (não no aplicativo Go). Por exemplo, uma instrução preparada pode ser pré-compilada no servidor de banco de dados e o servidor pode preparar o plano de execução da consulta, alocar certos recursos, como memória para ela. Estes podem ser permanentemente reservados até que a declaração preparada seja fechada.

Há um artigo (publicado por Myles McDonnell nos comentários abaixo) abordando os detalhes de implementação de Declarações preparadas em Go. Ele menciona que se as instruções preparadas não forem criadas a partir de transações, elas liberam a conexão de volta para o pool de conexões, mas quando necessário, tentam reutilizar a mesma em que foram preparadas (porque se o servidor db auxilia / também desempenha um papel ativo na instrução preparada, ele está vinculado à conexão no lado do servidor). Caso contrário, eles reprepararão em uma nova conexão (causando sobrecarga de desempenho indesejável).

Em suma, o que você descreve é ​​um modelo de trabalho, e se você tiver um número baixo de instruções preparadas que são necessárias/executadas em muitas solicitações subsequentes, elas podem significar tempos de resposta mais curtos. Mas isso também significa que, por outro lado, a longo prazo, eles podem resultar em que todas as suas declarações preparadas sejam preparadas em todas as conexões do pool. Decida se isso é aceitável no seu caso.

Em geral, isso deve ser evitado (e a instrução preparada deve ser fechada antes do final da solicitação HTTP), mas se você tiver apenas algumas delas e precisar delas em muitas solicitações uma após a outra, poderá movê-las para fora do escopo da solicitação .