MySQL (jak większość DBMS) buforuje plany wykonania dla przygotowanych instrukcji, więc jeśli użytkownik A utworzy plan dla:
SELECT * FROM some_table WHERE a_col=:v1 AND b_col=:v2
(gdzie v1 i v2 są zmiennymi wiązania) następnie wysyła wartości do interpolacji przez DBMS, a następnie użytkownik B wysyła to samo zapytanie (ale z różnymi wartościami do interpolacji) DBMS nie musi ponownie generować planu. tzn. to DBMS znajduje pasujący plan, a nie PDO.
Oznacza to jednak, że każda operacja na bazie danych wymaga co najmniej 2 podróży w obie strony (pierwsza do przedstawienia zapytania, druga do przedstawienia zmiennych wiązania) w przeciwieństwie do pojedynczej podróży w obie strony dla zapytania z wartościami literalnymi, co powoduje dodatkowe koszty sieciowe . Istnieje również niewielki koszt związany z wyłuskiwaniem (i utrzymywaniem) pamięci podręcznej zapytań/planów.
Kluczowe pytanie brzmi, czy ten koszt jest większy niż koszt wygenerowania planu w pierwszej kolejności.
Chociaż (z mojego doświadczenia) zdecydowanie wydaje się, że korzystanie z przygotowanych oświadczeń z Oracle zdecydowanie przynosi korzyści, nie jestem przekonany, że to samo dotyczy MySQL - jednak wiele będzie zależeć od struktury Twojej bazy danych i złożoności jej zapytanie (a dokładniej, ile różnych opcji optymalizator może znaleźć w celu rozwiązania zapytania).
Spróbuj sam to zmierzyć (wskazówka:możesz ustawić próg powolnego zapytania na 0 i napisać kod, aby przekonwertować wartości dosłowne z powrotem na anonimowe reprezentacje dla zapytań zapisanych w dziennikach).
