Hallo,
und wenn
die angenehme Nebenwirkung
durch den Hassel und Brassel des Bindens überlagert wird, dann lässt man es. Wenn die Binde-Birne zu sauer wird, dann beißt man lieber in den Escaping-Apfel. Irgendwas beißen muss man aber. Wenn nicht bei den SQL Zugriffen, dann in die Tischkante weil man gehackt wurde 😂
Die große Performance-Ersparnis bringt ein Prepare auf einem schwach belasteten Server ohnehin nicht. Der Server cached den Execution-Plan, den er für ein Statement erzeugt hat, und erkennt die Wiederverwendung. Auf einem stark belasteten Server mag dieser Cache überlaufen, so dass unnötig oft ein neuer Statement-Compile erfolgen muss.
Der Prepare sorgt dafür, dass der Plan erhalten bleibt, solange das Statement nicht mit close() geschlossen wird. Die "Rüstzeiten" für die eigentliche Ausführung werden damit reduziert.
Gelegentlich kann ein Prepare auch nachteilig sein. Wenn Du die Parameter im Statement direkt stehen hast, kann der Optimizer ggf. je nach Werten einen anderen Plan erzeugen, der performancetechnisch besser ist. Ob sowas passiert, kann man aber nicht abstrakt beantworten; das ist viel Erfahrung, genaue Kenntnis der Daten in der Datenbank und messen messen messen. Eventuell auch mal die Query mit unterschiedlichen Parametern vom MySQL explainen lassen. Messen kann man entweder mit DB-Tools, oder mit Stoppuhren in der Anwendung.
Wenn man den Eindruck gewinnt, dass ein bestimmtes Statement zu langsam ist, muss man mit Explains 'ran und gucken, ob es durch Indexe besser werden kann oder ob das technische Datenmodell untauglich ist. Es kann bei stark belasteten Datenbanken z.B. nötig werden, bestimmte Spalten, die im konzeptionellen Modell normalisiert sind, im technischen Modell zu denormalisieren, d.h. bewusst Redundanzen zuzulassen. Man muss dann mit den Konsequenzen leben, die Redundanzen bei Updates nun mal haben, hat aber ggf. eine deutliche Beschleunigung der Lesezugriffe.
Rolf
sumpsi - posui - clusi