Warum mysql_* in PHP böse ist: Eine vollständige Analyse mit Beispielen

Die Geschichte eines Fehlers: Warum mysql_* das letzte Jahrhundert ist

Stellen Sie sich vor: Sie schreiben eine Website in PHP, verbinden sich mit einer MySQL-Datenbank und verwenden die aus dem Studium bekannte Funktion mysql_query(). Alles funktioniert, die Website lebt, die Benutzer sind zufrieden. Aber eines Tages bemerken Sie eine seltsame Warnung in den Logs: „Deprecated: mysql_connect(): The mysql extension is deprecated and will be removed in the future“. Dies ist nicht nur ein Schimpfen des Interpreters – es ist eine rote Flagge, die man nicht ignorieren sollte.

Auf Stack Overflow hat die Frage „Why shouldn't I use mysql_* functions in PHP?“ Tausende von Aufrufen und Hunderte von Kommentaren gesammelt. Und das ist kein Zufall. In diesem Artikel werden wir analysieren, warum mysql_*-Funktionen (mysql_connect, mysql_query, mysql_fetch_array und andere) zum Feind Nummer eins für PHP-Entwickler geworden sind, anhand realer Codebeispiele zeigen, womit man sie ersetzen kann, und einen schrittweisen Migrationsplan geben.

Was sind mysql_* und warum wurden sie entfernt?

Die Erweiterung mysql_* (ursprüngliches MySQL) erschien in PHP 2.0 im fernen Jahr 1997. Sie war einfach und intuitiv: mysql_connect() aufgerufen, eine Abfrage über mysql_query() ausgeführt, das Ergebnis erhalten. Aber diese Einfachheit hatte eine dunkle Seite.

Ab PHP 5.5.0 wurden alle mysql_*-Funktionen als veraltet (deprecated) markiert, und in PHP 7.0 wurden sie vollständig entfernt. Wenn Sie versuchen, mysql_connect() unter PHP 7+ zu verwenden, erhalten Sie einen fatalen Fehler: Call to undefined function mysql_connect(). Der Grund dafür ist keine Laune der PHP-Entwickler, sondern fundamentale Sicherheits- und Architekturprobleme.

Drei Hauptgründe, auf mysql_* zu verzichten

\n
• SQL-Injection ohne Schutz – die Funktionen unterstützen keine Prepared Statements, was manuelles Escaping obligatorisch, aber oft vergessen macht.
\n
• Veraltete Architektur – es gibt keine Unterstützung für objektorientierten Stil, gespeicherte Prozeduren, mehrere Abfragen und Transaktionen.
\n
• Fehlende Weiterentwicklung – die Erweiterung wurde jahrelang nicht aktualisiert, während sich MySQL veränderte (z. B. neue Datentypen, Zeichensätze, Authentifizierungsmechanismen).
\n

Lebendiges Beispiel: Wie mysql_* Ihre Website tötet

Schauen wir uns einen klassischen Code an, der immer noch in alten Lehrbüchern und Foren zu finden ist:

<?php\n// VERALTETER CODE - NICHT VERWENDEN!\n$link = mysql_connect('localhost', 'root', 'password');\nmysql_select_db('users_db', $link);\n\n$user_input = $_GET['username']; // Benutzer gibt ein: ' OR 1=1 --\n$query = "SELECT * FROM users WHERE username = '$user_input'";\n$result = mysql_query($query, $link);\n\nwhile ($row = mysql_fetch_assoc($result)) {\n    echo "Hallo, " . $row['username'] . "<br>";\n}\n?>

Wo liegt das Problem? Wenn ein Angreifer im Parameter username den Wert ' OR 1=1 -- übergibt, wird die Abfrage zu:

SELECT * FROM users WHERE username = '' OR 1=1 --

Der doppelte Bindestrich -- kommentiert den Rest der Abfrage aus, und die Bedingung 1=1 ist immer wahr. Als Ergebnis erhalten Sie alle Benutzer der Datenbank, einschließlich Passwörter, E-Mails und anderer vertraulicher Informationen. Das ist keine Theorie – das ist eine reale Sicherheitslücke, die täglich Tausende von Websites lahmlegt.

Natürlich könnte man mysql_real_escape_string() verwenden, aber:

\n
• Entwickler vergessen oft, es aufzurufen.
\n
• Es schützt nicht vor allen Arten von Angriffen (z. B. vor Angriffen mit Zeichensätzen).
\n
• Der Code wird unübersichtlich und schwer lesbar.
\n

Womit mysql_* ersetzen: Zwei moderne Ansätze

Im modernen PHP gibt es zwei würdige Erweiterungen für die Arbeit mit MySQL: mysqli (MySQL Improved) und PDO (PHP Data Objects). Beide unterst