Sangreal

Hallo zusammen,

mit der PHP-Erweiterung MySQLi sind - wie die meistens von euch vermutlich wissen werden - Prepared Statements möglich.
Zur Zeit arbeite ich an einem größeren Projekt, in dem natürlich auch etliche Queries anfallen. Da es noch gar nicht so lange her ist, dass ich von der alten Erweiterung auf MySQLi umgestiegen bin, verzichte ich vor allem bei einfachen Anfragen in der Regel noch auf Prepared Statements, die entsprechenden Variablen werden also einfach "wie früher" in den String eingefügt. Escaped werden kritische Daten bei mir sowieso.
Einzig für komplexere SQL-Statements finde ich Prepared Statements momentan praktischer, da diese dadurch sehr viel übersichtlicher werden.

Ich stelle mir nun allerdings die Frage, ob es Sinn macht, umfassend mit Prepared Statements zu arbeiten. Mich würde deshalb interessieren, in wie weit bei euch Prepared Statements zum Einsatz kommen und ob ihr eventuelle Performance-Einbußen seht, da pro Statement ja mindestens eine "Suchen & Ersetzen"-Operation durchgeführt werden muss.

Viele Grüße,
Basti

__________________
Webentwicklung in PHP // slyfox CMS // Webdesign Forum

Mister Ad

fat32

Also ich verwende nie PS und hatte so auch noch nie Probleme.
Ich frage mich sowieso, was mir das für Vorteile bringen soll

erc

Irgendwas passt hier nicht zusammen... Mysqli, prepared und übersichtlich? Da bekomm ich nachts Albträume von Fragezeichen Mit der Variante von PDO kann ich mich da schon eher anfreuden. Persönlich verwenden tuh ich sie aber auch nur wenns Pluspunkte bringt... sprich wenn ich ein und den selben Query x mal ausführen muss, ansonsten bin ich kein Fan davon.

Schon mal mit Prepared Statments getestet? Ein Escapen (escapen != validieren) ist völlig unnötig und noch dazu kontraproduktiv (die Escapesequenzen werden einfach mit gespeichert). Überleg dir mal zuwas escapen da ist und wie Prepared Statments funktionieren. Und wenn du weißt wie ein Prepared Statment funktioniert kannst du dir die Frage der Performance auch selbst beantworten.

robo47

Unter gewissen Umständen können prepared Statements schneller sein, z.b. wenn man ein query mehrfach ausführt mit unterschiedlichen Parameter, aber der Query-Cache von mysql wird von prepared Statements z.b. erst seit 5.1.17 unterstützt und auch nicht in allen Fällen.

__________________
robo47.net - Blog, Codeschnipsel und mehr
| Caching-Klassen und Opcode Caches in php | Robo47 Components - PHP Library extending Zend Framework

Phoscur

Hab mal lokal nen Test gemacht, Update über mehrere Einträge...
Alternativ zu PS gibt es nämlich noch CASE und somit ein Update über mehrere Einträge. Genaueres Resultat ist auf meinem Blog zu finden.
Ich konnte feststellen, dass die PS eindeutig langsamer sind, aber sehr gut skalieren, was bei dem CASE nicht der Fall ist.

Ich glaube nicht, dass es einen wirklichen Overhead durch das Ersetzen gibt. Stilistisch könnte es sogar schön und sicher sein, ist daher wohl nur zu empfehlen. Wenn du nun auf Performance aus bist, sparst du am besten mit der Anzahl der Queries.

Wenn du dich an MySQL binden willst, kannst du dir noch Stored Procedures ansehen, die gehen auch sehr schnell, wobei man dort vor allem mit Cursors sparsam sein sollte, meist braucht man sie auch gar nicht.

__________________

brian johnson

prepared statements, transaktionen, utf8 und xml und der brian ist glücklich

hast du die werte die du abändern wolltest auch durch eine escape funktion gejagt? dafür sind Prepared Statements nämlich eigentlich da, nicht escapen zu müssen.

auch der mysql server muss den query wieder umsetzen, also parsen. da es egal ist ob er ein ? oder einen wert parsed, ists auch jacke wie hose.

__________________
PHP4?!?>>>Aktuelle PHP Version: 5.2.11 || 5.3.0
Suse 11.2 *vorfreude*

hondatuner

Vielleicht eine blöde Frage, aber wie lange sind PS eigentlich "aktiv". Also machen die nur Sinn, wenn ich innerhalb einer Verbindung den gleichen Query mit unterschiedlichen Vergleichswerten abfrage oder macht das auch global Sinn, da der Cache für jede Verbindung verfügbar ist?

Ansonsten sehe ich nicht den Sinn in PS, weil wiederholte Querys mit unterschiedlichen Parametern, kann ich ja gleich mit ID IN(1,2,3) lösen.

Wenn es global geht, woher weiß ich das der Cache dafür schon vorhanden ist? Oder setzt man ihn auf Verdacht hin, dass er noch nicht da ist, einfach immer neu?

Die Kommentare hier helfen da leider gar nicht:
http://dev.mysql.com/tech-resources/...tatements.html

__________________
meine PHP Scripte

hondatuner

Ich habe mir mal die Mühe gemacht und alle nur denkbaren SELECT-Varianten in ein Benchmark gepackt. Hier die Ergebnisse:
Benchmark: mysql, mysqli - Buffer, Cache und Prepared Stmt - Forum: PHP

Unter dem Strich heißt das für mich aktuell, dass PS nur für bestimmte Einsatzzwecke Sinn macht, aber sicher nicht global.

__________________
meine PHP Scripte

robo47

Ich denke mal sehr relevant dabei wäre auch zu wissen welche Version von PHP und mysql verwendet wurden, da sowohl php seit 5.2 einige Sachen im zusammenhang mit der nutzung des Caches von mysql verbessert hat und auch mysql sein Verhalten etwas verändert hat.

Beim Einsatz von PHP 5.3 ist dann auch noch relevant ob php mit libmysql kompiliert wurde oder ob es das neue von mysql selbst für php optimierte backend mysqlnd nutzt.

Was mir vor allem fehlt ist PDO (das im Zusammenspiel mit aktuellen Versionen von PHP und mysql mittlerweile auch den Cache nutzen kann)

Und ein paar Details zum Ablauf des des Benchmarks, inwieweit wurde mysql jedes mal neu gestartet um einen gleichen start zu ermöglichen ... etc.

__________________
robo47.net - Blog, Codeschnipsel und mehr
| Caching-Klassen und Opcode Caches in php | Robo47 Components - PHP Library extending Zend Framework

hondatuner

PDO kannst Du (noch) vergessen. Der Anspruch von PDO liegt nicht darin schneller als mysqli zu sein. Dazu gibt es schon genug Benchmarks und die zeigen eigentlich sehr klar, dass PDO 3-4x langsamer als mysqli ist. Wenn gewünscht, erweitere ich aber den Test um die entsprechenden PDO Varianten.

Serverdaten:
PHP Version 5.2.9-1nmm1
MySQL Version 5.0.51a
AMD Phenom QuadCore
8 GB Arbeitsspeicher
750 GB Festplatte SATA
Hardware-RAID 1

Besondere Optimierungen in Richtung MySQL gibt es nicht, da ich nicht glaube, dass die das Ergebnis wirklich umkehren können.

In wie weit nun PHP mit dem CACHE von MySQL besser umgehen können soll, kann ich allerdings nicht ganz verstehen. Wenn dann kann doch nur MySQL den Cache verbessern?! Oder meinst Du den PHP Buffer?

Die DB wurde einmal pro Seitenimpression konnektiert, die Abfrage 50 mal durch eine Schleife gejagt und das ganze 100x wiederholt. Die Zeit ist dann der Schnitt aus allen 100 Versuchen.

__________________
meine PHP Scripte