mepeisen

Bei Benchmarks ist immer auch wichtig, zu erläutern, was man messen will. Alleine die Tatsache, dass es keinen messbaren Unterschied ergibt, heißt noch lange nicht, dass kein Unterschied feststellbar ist. Dazu muss ich aber etwas ausholen.

Generell arbeitet jede moderne Datenbank in mehreren Stufen einen Query ab.
1. Stufe: Analyse des eingegebenen Statements
2. Stufe: Ermitteln des geschicktesten Ablaufs/ Zugriffspfads
3. Stufe: Zugriff auf die Datenbanktabellen, evtl. Nutzen von Indices für Where-Bedingungen usw.
4. Stufe: Bilden der Ergebnismenge, evtl. höherstufige MySQL-Funktionen usw.

Prepared Statements kommen genau dann zum Tragen, wenn Stufe 1 und Stufe 2 zuschlagen, also die eigentliche Analyse des Statements. Aufgrund der dynamischen Struktur (eine DB rechnet immer mit einem völlig neuen Query) muss die Analyse normalerweise immer aufs neue durchlaufen werden. Genau dann, wenn die Analyse des Query aufwändig ist, genau dann "lohnt" sich ein Prepared-Statement. Aber auch nur dann, wenn man es richtig nutzt. Ein Statement zu preparen, um es dann genau einmal zu verwenden, ist aus Performance-Sicht überflüssig.

Nun kommt das große ABER. Wenn ein Query prepared wird, ist der Wiederkennungseffekt für die Datenbank oder den Treiber oder sonstwas gegeben. Selbst wenn es nicht im gleichen Prozess zweimal verwendet wird, kann die Datenbank durch geschickten Query-Cache die optimalen Zugriffspfade cachen und somit bei aufwändigen Queries die Analyse-Phase auf einen schnellen Cache-Zugriff minimieren. Zudem werden aufwändige Optimierungsmethoden (darunter fällt beispielsweise die Entscheidung, ob ein Index-Zugriff möglich ist oder nicht) nicht unnötig oft von der DB vorgenommen.

Wann sich also Prepared Statements lohnen und wann nicht, kann man so pauschal kaum beanworten. Das hängt vor allem auch von äußeren Einflüssen wie Aufrufhäufigkeit, Wiedererkennungswert, Komplexität und Menge der Daten, User-Verhalten usw ab. Und natürlich, wie robo schon richtig sagt, auch von den verwendeten Treibern/Versionen.

Dein Benchmark geht leider am Thema vorbei, denn der Analyse-Overhead ist durch die Einfachheit deines Queries bereits derart minimal, dass andere Schritte (Kommunikation/Datenübermittlung, Festplattenzugriff) wohl zu 99% die Laufzeit der Queries ausmachen. Dann ist der Vorteil nahezu nicht messbar.

Die Frage, die man sich eher stellen sollte: Sind prepared statements langsamer als "normale" und wenn ja: Fällt dieser Nachteil überhaupt ins Gewicht. Hier fehlen mir die Erfahrungswerte aber in aller Regel sind die Laufzeit-Nachteile der prepared statements und die erhöhte Netzwerkkommunikation derart gering, dass alle Vorteile gerade bzgl. besserem Cachings, die Nachteile überwiegen.

P.S.: Durch das Verwenden eines Query-Cache ist bereits der Wiederekennungseffekt für den Query gegeben, so dass prepared statements eigentlich überflüssig sind. Aber gerade bei unterschiedlichen Where-Bedingungen kann ein zusätzliches Prepare noch weitere Vorteile bringen.

__________________
www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

Mister Ad