Przygotowane instrukcje są po to, aby można było wykonywać powtarzające się polecenia SQL, które na przykład mogą różnić się tylko wartościami parametrów.
Nie mają one żyć „długo”, ponieważ przygotowana instrukcja może (robią to, jeśli zostanie wywołana z transakcji) zarezerwować aktywne połączenie z bazą danych („długie” oznacza, że nie są używane; doskonale jest powtarzalne wykonywanie przygotowanej instrukcji wiele razy, nawet jeśli to potrwa długo). Połączenie jest kosztownym zasobem i powinno być utrzymywane tylko tak długo, jak jest to potrzebne. Po prostu tworząc kilka przygotowanych instrukcji i nie zamykając ich, możesz zabraknąć aktywnych / dozwolonych połączeń, a następnie zablokować dalszą komunikację z serwerem db.
Użyj przygotowanej instrukcji, jeśli chcesz wykonać to samo insert , update lub select oświadczenie z różnymi parametrami wielokrotnie w jednym żądaniu (HTTP). Nie używaj przygotowanych wyciągów do przetrwania żądań (HTTP).
W niektórych implementacjach sterowników i serwerach baz danych przygotowane instrukcje mogą również obejmować zasoby przydzielone na samym serwerze DB (nie w aplikacji Go). Na przykład przygotowana instrukcja może być wstępnie skompilowana na serwerze DB, a serwer może przygotować plan wykonania zapytania, przydzielić dla niego określone zasoby, takie jak pamięć. Mogą one zostać na stałe zarezerwowane do czasu zamknięcia przygotowanego zestawienia.
Jest artykuł (opublikowany przez Myles McDonnell w komentarzach poniżej) omawiający szczegóły implementacji Przygotowane oświadczenia w Go. Wspomina, że jeśli przygotowane zestawienia nie są tworzone z transakcji, zwalniają połączenie z powrotem do puli połączeń, ale w razie potrzeby próbują ponownie wykorzystać to samo, na którym zostały przygotowane (ponieważ jeśli serwer db pomaga / również odgrywa aktywną rolę w przygotowanym zestawieniu jest on powiązany z połączeniem po stronie serwera). Jeśli nie, przygotują się ponownie je na nowym połączeniu (powodując niepożądane obciążenie wydajności).
W sumie to, co opisujesz, to działający model, a jeśli masz mało przygotowanych instrukcji, które są potrzebne/wykonane w wielu kolejnych żądaniach, mogą to oznaczać krótsze czasy odpowiedzi. Ale oznacza to również, że z drugiej strony na dłuższą metę mogą one skutkować tym, że wszystkie przygotowane przez Ciebie zestawienia będą przygotowane na wszystkich połączeniach puli. Zdecyduj, czy jest to dopuszczalne w Twoim przypadku.
Generalnie należy tego unikać (a przygotowaną instrukcję zamykać przed końcem żądania HTTP), ale jeśli masz ich tylko kilka i potrzebujesz ich w wielu żądaniach następujących po sobie, możesz przenieść je poza zakres żądania .
