Vergewissern Sie sich zunächst, dass der Server auch ausgeführt wird. Läuft er nicht, dann können Sie auch keine Verbindung herstellen. Wenn Sie beispielsweise versuchen, eine Verbindung zum Server herzustellen, und eine Meldung wie die folgende angezeigt wird, dann kann Ursache hierfür auch sein, dass der Server schlichtweg nicht läuft:

shell> mysql
ERROR 2003: Can't connect to MySQL server on 'host_name' (111)
shell> mysql
ERROR 2002: Can't connect to local MySQL server through socket
'/tmp/mysql.sock' (111)

Ferner ist es möglich, dass der Server zwar ausgeführt wird, Sie aber eine Verbindung über einen TCP/IP-Port, eine Named Pipe oder eine Unix-Socketdatei herstellen wollen, die nicht mit der Ressource übereinstimmt, auf der der Server horcht. Um dieses Problem zu beheben, geben Sie beim Aufruf eines Clientprogramms eine Option --port oder --socket an, um die korrekte Portnummer bzw. Named Pipe oder Unix-Socketdatei anzugeben. Mithilfe des folgenden Befehls ermitteln Sie, wo die Socketdatei sich befindet:

shell> netstat -ln | grep mysql

Die Grant-Tabellen müssen korrekt konfiguriert sein, damit der Server sie zur Zugriffssteuerung verwenden kann. Bei einigen Distributionstypen (z. B. Binärdistributionen für Windows oder RPM-Distributionen für Linux) initialisiert der Installationsvorgang die mysql-Datenbank, die die Grant-Tabellen enthält. Wenn Ihre Distribution dies nicht tut, dann müssen Sie die Grant-Tabellen manuell initialisieren, indem Sie das Skript mysql_install_db ausführen. Detaillierte Informationen finden Sie in Abschnitt 2.9.2, „Schritte nach der Installation unter Unix“.

Eine Möglichkeit, zu ermitteln, ob Sie die Grant-Tabellen initialisieren müssen, besteht darin, nach einem Verzeichnis mysql zu suchen, das sich im Datenverzeichnis befindet. (Das Datenverzeichnis heißt normalerweise data oder var und befindet sich seinerseits im MySQL-Installationsverzeichnis.) Vergewissern Sie sich, dass eine Datei namens user.MYD im Datenverzeichnis mysql vorhanden ist. Sollte dies nicht der Fall sein, dann führen Sie das Skript mysql_install_db aus. Nach Ausführung des Skripts und dem Starten des Servers können Sie die anfänglich vorhandenen Berechtigungen durch Ausführung des folgenden Befehls überprüfen:

shell> mysql -u root test

Der Server sollte die Herstellung dieser Verbindung ohne Fehler gestatten.

Nach einer frischen Installation sollten Sie eine Verbindung mit dem Server herstellen und Ihre Benutzer und deren Zugriffsberechtigungen einrichten:

shell> mysql -u root mysql

Der Server sollte diese Verbindung gestatten, da der MySQL-Benutzer root anfänglich kein Passwort hat. Dies ist natürlich auch ein Sicherheitsrisiko d. h. Sie sollten das Passwort für das root-Konto einrichten, während Sie auch die übrigen MySQL-Konten konfigurieren. Anweisungen zur Einstellung der anfänglichen Passwörter finden Sie in Abschnitt 2.9.3, „Einrichtung der anfänglichen MySQL-Berechtigungen“.

Haben Sie, sofern Sie eine vorhandene MySQL-Installation auf eine neuere Version aktualisiert haben, das Skript mysql_fix_privilege_tables ausgeführt? Wenn nicht, holen Sie dies schleunigst nach. Die Struktur der Grant-Tabellen ändert sich ab und an, wenn neue Funktionalitäten hinzugefügt werden. Deswegen sollten Sie nach einem Upgrade immer sicherstellen, dass Ihre Tabellen die aktuell gültige Struktur aufweisen. Informationen zur Vorgehensweise finden Sie in Abschnitt 5.6, „mysql_fix_privilege_tables — Upgrade von MySQL-Systemtabellen“.

Wenn ein Clientprogramm beim Verbindungsversuch die folgende Fehlermeldung erhält, bedeutet dies, dass der Server Passwörter in einem neueren Format als dem erwartet, das der Client erzeugen kann:

shell> mysql
Client does not support authentication protocol requested
by server; consider upgrading MySQL client

Informationen dazu, wie Sie in diesem Fall verfahren, finden Sie in Abschnitt 5.8.9, „Kennwort-Hashing ab MySQL 4.1“, und Abschnitt A.2.3, „Client does not support authentication protocol“.

Wenn Sie eine Verbindung als root herstellen und die folgende Fehlermeldung erhalten, dann heißt das, dass kein Datensatz in der Tabelle user gefunden wurde, der in der Spalte User den Wert 'root' aufweist – mysqld kann den Hostnamen Ihres Clients in diesem Fall nicht auflösen:

Access denied for user ''@'unknown' to database mysql

Sie müssen den Server in einem solchen Fall mit der Option --skip-grant-tables neu starten und in Ihrer Datei /etc/hosts bzw. \windows\hosts einen Eintrag für den Host hinzufügen.

Zur Erinnerung: Clientprogramme verwenden Verbindungsparameter, die in Optionsdateien oder über Umgebungsvariablen angegeben sind. Wenn ein Clientprogramm offensichtlich unzutreffende Standardverbindungsparameter sendet, weil Sie auf der Befehlszeile keine entsprechenden Informationen angegeben haben, überprüfen Sie die Umgebung und alle relevanten Optionsdateien. Wenn Sie beispielsweise bei der Ausführung eines Clients ohne Optionen die Fehlermeldung Access denied erhalten, vergewissern Sie sich, dass Sie in keiner Ihrer Optionsdateien ein altes Passwort angegeben haben!

Sie können die Verwendung von Optionsdateien durch ein Clientprogramm unterdrücken, indem Sie es mit der Option --no-defaults aufrufen. Zum Beispiel:

shell> mysqladmin --no-defaults -u root version

Die von Clients verwendeten Optionsdateien sind in Abschnitt 4.3.2, „my.cnf-Optionsdateien“ aufgelistet. Umgebungsvariablen werden in Anhang F, Umgebungsvariablen beschrieben.

Wenn Sie die folgende Fehlermeldung erhalten, bedeutet dies, dass Sie das falsche root-Passwort benutzen:

shell> mysqladmin -u root -pxxxx ver
Access denied for user 'root'@'localhost' (using password: YES)

Wenn dieser Fehler auftritt, obwohl Sie gar kein Passwort angegeben haben, ergibt sich daraus, dass ein falsches Passwort in irgendeiner Optionsdatei aufgeführt sein muss. Probieren Sie in diesem Fall die Option --no-defaults wie im vorhergehenden Abschnitt beschrieben aus.

Informationen zur Änderung von Passwörtern finden Sie in Abschnitt 5.9.5, „Kennwörter einrichten“.

Haben Sie das root-Passwort verloren oder vergessen, dann können Sie mysqld mit --skip-grant-tables neu starten, um das Passwort zu ändern. Siehe auch Abschnitt A.4.1, „Wie ein vergessenes Kennwort zurückgesetzt wird“.

Wenn Sie ein Passwort mit SET PASSWORD, INSERT oder UPDATE ändern, müssen Sie es mit der Funktion PASSWORD() verschlüsseln. Verwenden Sie PASSWORD() für diese Anweisungen nicht, dann funktioniert das Passwort nicht. So wird mit der folgenden Anweisung ein Passwort zwar eingestellt, aber nicht verschlüsselt – und der Benutzer kann nachfolgend keine Verbindung herstellen:

SET PASSWORD FOR 'abe'@'host_name' = 'eagle';

Stattdessen muss das Passwort wie folgt eingestellt werden:

SET PASSWORD FOR 'abe'@'host_name' = PASSWORD('eagle');

Die Funktion PASSWORD() ist entbehrlich, wenn Sie ein Passwort mit GRANT- oder CREATE USER-Anweisungen oder dem Befehl mysqladmin password festlegen. Sie alle verschlüsseln das Passwort automatisch mit PASSWORD(). Siehe auch Abschnitt 5.9.5, „Kennwörter einrichten“, und Abschnitt 13.5.1.1, „CREATE USER“.

localhost ist ein Synonym für Ihren lokalen Hostnamen und zudem der standardmäßige Host, mit dem Clients eine Verbindung herzustellen versuchen, wenn Sie keinen Host explizit angeben.

Um dieses Problem auf solchen Systemen zu umgehen, können Sie die Option --host=127.0.0.1 verwenden, um den Serverhost explizit anzugeben. Hierdurch wird eine TCP/IP-Verbindung mit dem lokalen mysqld-Server hergestellt. Sie können TCP/IP auch verwenden, indem Sie eine Option --host angeben, die den eigentlichen Hostnamen des lokalen Hosts verwendet. In diesem Fall muss der Hostname in einem Datensatz in der Tabelle user auf dem Serverhost angegeben sein, auch wenn Sie das Clientprogramm auf demselben Host wie den Server ausführen.

Wenn Sie die Fehlermeldung Access denied erhalten, wenn Sie mit mysql -u user_name eine Verbindung zur Datenbank herstellen, liegt unter Umständen ein Problem mit der Tabelle user vor. Sie können dies überprüfen, indem Sie mysql -u root mysql ausführen und die folgende SQL-Anweisung absetzen:

SELECT * FROM user;

Das Ergebnis sollte einen Datensatz mit Host- und User-Spaltenwerten enthalten, die mit dem Hostnamen Ihres Computers bzw. Ihrem MySQL-Benutzernamen übereinstimmen.

Die Fehlermeldung Access denied sagt Ihnen, als wer Sie eine Verbindung herzustellen versuchen, von welchem Clienthost Sie diese Verbindung herzustellen versuchen und ob Sie ein Passwort angegeben haben. Normalerweise sollte genau ein Datensatz in der Tabelle user vorhanden sein, für den eine Übereinstimmung mit dem Host- und dem Benutzernamen vorliegt, die in der Fehlermeldung angegeben werden. Erhalten Sie beispielsweise eine Fehlermeldung, die using password: NO enthält, dann bedeutet dies, dass Sie versucht haben, sich ohne Passwort anzumelden.

Tritt der folgende Fehler auf, wenn Sie versuchen, eine Verbindung von einem anderen als dem Host herzustellen, auf dem der MySQL-Server ausgeführt wird, dann bedeutet dies, dass in der Tabelle user kein Datensatz mit einem zum Clienthost passenden Host-Wert gefunden wurde:

Host ... is not allowed to connect to this MySQL server

Sie können dieses Problem beheben, indem Sie ein Konto für die Kombination aus Clienthostname und Benutzername erstellen, die Sie zur Verbindungsherstellung verwenden.

Wenn Sie IP-Adresse oder Hostname des Computers, von dem aus Sie die Verbindung herstellen, nicht kennen, dann sollten Sie einen Datensatz mit dem Wert '%' in die Spalte Host der Tabelle user einfügen. Nachdem Sie versucht haben, eine Verbindung vom Clientsystem herzustellen, ermitteln Sie mit einer SELECT USER()-Abfrage, wie Sie die Verbindung tatsächlich hergestellt haben. (Ändern Sie nachfolgend den Eintrag '%' im betreffenden Datensatz der Tabelle user zu dem im Log angegebenen Hostnamen. Wenn Sie dies versäumen, bleibt Ihr System unsicher, da es dem angegebenen Benutzernamen Verbindungen von jedem Host aus gestattet.)

Unter Linux kann ein anderer Grund für diese Fehlermeldung darin bestehen, dass Sie eine aus einer Binärdistribution stammende MySQL-Version verwenden, die mit einer anderen Version der glibc-Bibliothek als der von Ihnen verwendeten kompiliert wurde. In diesem Fall sollten Sie entweder Ihr Betriebssystem oder glibc aktualisieren oder eine Quelldistribution der MySQL-Version herunterladen und selbst kompilieren. Dies ist kein Problem, da Kompilierung und Installation eines Quellcode-RPM in der Regel einfach und schnell erledigt sind.

Wenn Sie beim Verbindungsversuch einen Hostnamen angeben, aber eine Fehlermeldung erhalten, in der der Hostname nicht oder an seiner Stelle eine IP-Adresse angegeben ist, dann bedeutet dies, dass am MySQL-Server bei dem Versuch, die IP-Adresse des Clients in einen Namen aufzulösen, ein Fehler aufgetreten ist:

shell> mysqladmin -u root -pxxxx -h some_hostname ver
Access denied for user 'root'@'' (using password: YES)

Dies weist auf ein DNS-Problem hin. Um es zu beheben, setzen Sie den internen DNS-Hostnamens-Cache durch Ausführen von mysqladmin flush-hosts zurück. Siehe auch Abschnitt 7.5.6, „Wie MySQL DNS benutzt“.

Die folgenden Lösungen versprechen dauerhaften Erfolg:

Wenn mysql -u root test funktioniert, aber mysql -h your_hostname -u root test zur Fehlermeldung Access denied führt (wobei your_hostname der tatsächliche Hostname des lokalen Hosts ist), dann steht unter Umständen für Ihren Host nicht der korrekte Name in der Tabelle user. Ein häufig auftretendes Problem besteht hier darin, dass der Host-Wert des Datensatzes in der Tabelle user einen unqualifizierten Hostnamen angibt, die Namensauflösungsroutinen Ihres Systems aber einen vollqualifizierten Domänennamen zurückgeben (oder umgekehrt). Wenn Sie also beispielsweise einen Eintrag mit dem Host 'tcx' in der Tabelle user haben, aber Ihr DNS MySQL meldet, dass Ihr Hostname 'tcx.subnet.se' lautet, dann funktioniert der Eintrag nicht. Versuchen Sie, der Tabelle user einen Eintrag hinzufügen, der die IP-Adresse Ihres Hosts als Host-Spaltenwert enthält. (Alternativ können Sie einen Eintrag in der Tabelle user mit einem Host-Wert hinzufügen, der ein Jokerzeichen enthält – z. B. 'tcx.%'. Allerdings ist die Verwendung von Hostnamen, die auf ‘%’ enden, ein Sicherheitsrisiko. Wir raten dringend davon ab!)

Wenn mysql -u user_name test funktioniert, mysql -u user_name other_db_name aber nicht, dann haben Sie dem betreffenden Benutzer keinen Datenbankzugriff auf other_db_name gewährt.

Wenn mysql -u user_name bei einer Ausführung auf dem Serverhost funktioniert, mysql -h host_name -u user_name jedoch bei der Ausführung auf dem Clienthost jedoch nicht, dann haben Sie für den betreffenden Benutzernamen den Zugriff vom entfernten Host auf den Server nicht aktiviert.

Wenn Sie nicht feststellen können, warum Sie den Fehler Access denied erhalten, entfernen Sie aus der Tabelle user alle Einträge, die Host-Werte mit Jokerzeichen aufweisen (d. h. Einträge, die ‘%’ oder ‘_’ enthalten). Ein sehr häufiger Fehler besteht darin, einen neuen Eintrag mit Host='%' und User='some_user' einzufügen, weil man der Ansicht ist, dass dies die Angabe von localhost zur Verbindung von demselben Computer aus ermöglicht. Der Grund dafür, dass dies nicht funktioniert, ist, dass die Standardberechtigungen einen Eintrag mit Host='localhost' und User='' enthalten. Da dieser Eintrag einen Host-Wert 'localhost' aufweist, der spezifischer ist als '%', wird er anstelle des neuen Eintrags verwendet, wenn eine Verbindung von localhost aus hergestellt wird! Die korrekte Vorgehensweise besteht darin, einen zweiten Eintrag mit Host='localhost' und User='some_user' einzufügen oder den Eintrag mit Host='localhost' und User='' zu löschen. Nach dem Löschen des Eintrags dürfen Sie nicht vergessen, eine FLUSH PRIVILEGES-Anweisung abzusetzen, um die Grant-Tabellen neu zu laden.

Wenn Sie den folgenden Fehler erhalten, liegt unter Umständen ein Problem mit den Tabellen db oder host vor:

Access to database denied

Wenn der in der Tabelle db gewählte Eintrag einen leeren Wert in der Spalte Host aufweist, müssen Sie sicherstellen, dass mindestens ein entsprechender Eintrag in der Tabelle host vorhanden ist, der angibt, für welche Hosts der Eintrag in der Tabelle db gilt.

Wenn Sie eine Verbindung mit dem MySQL-Server herstellen können, aber immer dann eine Fehlermeldung Access denied erhalten, wenn Sie eine SELECT ... INTO OUTFILE- oder LOAD DATA INFILE-Anweisung absetzen, ist für Ihren Eintrag in der Tabelle user die Berechtigung FILE nicht aktiviert.

Ändern Sie die Grant-Tabellen direkt (z. B. mit INSERT, UPDATE oder DELETE) und werden Ihre Änderungen offenbar ignoriert, dann dürfen Sie nicht vergessen, eine FLUSH PRIVILEGES-Anweisung oder den Befehl mysqladmin flush-privileges auszuführen, damit der Server Ihre Berechtigungstabellen neu einliest. Andernfalls werden Ihre Änderungen erst beim nächsten Neustart des Servers umgesetzt. Denken Sie auch immer daran, dass Sie, wenn Sie das root-Passwort mit einem UPDATE-Befehl geändert haben, das neue Passwort erst nach dem Schreiben der Berechtigungen angeben müssen, da der Server vorher gar nicht weiß, dass Sie Ihr Passwort geändert haben!

Wenn Ihre Berechtigungen im Verlauf einer Sitzung offensichtlich geändert werden, besteht die Möglichkeit, dass ein MySQL-Administrator die Änderungen vorgenommen hat. Das Neuladen der Grant-Tabellen wirkt sich auf neue Clientverbindungen, aber auch auf vorhandene Verbindungen aus (siehe auch Abschnitt 5.8.7, „Wann Berechtigungsänderungen wirksam werden“).

Wenn Sie bei einem Perl-, PHP-, Python- oder ODBC-Programm Probleme mit dem Zugriff haben, sollten Sie versuchen, eine Serververbindung mit mysql -u user_name db_name oder mysql -u user_name -pyour_pass db_name herzustellen. Wenn Sie eine Verbindung mit dem mysql-Client herstellen können, wird das Problem von Ihrem Programm und nicht von den Zugriffsberechtigungen verursacht. (Zwischen -p und dem Passwort ist kein Leerzeichen vorhanden; Sie können auch die Syntax --password=your_pass zur Angabe des Passworts verwenden. Wenn Sie die Option -p bzw. --password ohne Passwortwert benutzen, fordert Sie MySQL zur Eingabe des Passworts auf.)

Zu Testzwecken starten Sie den mysqld-Server mit der Option --skip-grant-tables. Sie können dann die MySQL-Grant-Tabellen ändern und das Skript mysqlaccess zur Überprüfung verwenden, ob Ihre Änderungen die gewünschte Wirkung hervorrufen. Wenn Sie mit den Änderungen zufrieden sind, führen Sie mysqladmin flush-privileges aus, um dem mysqld-Server anzuweisen, die neuen Grant-Tabellen ab sofort zu verwenden. (Das Neuladen der Grant-Tabellen hat Vorrang vor der Option --skip-grant-tables. Dies ermöglicht Ihnen, den Server zur sofortigen Verwendung der neuen Grant-Tabellen anzuweisen, ohne dass ein Serverneustart erforderlich wäre.)

Wenn alles andere fehlschlägt, starten Sie den mysqld-Server mit einer Debug-Option (z. B. --debug=d,general,query). Hierdurch werden Host- und Benutzerinformationen zu Verbindungsversuchen sowie Angaben zu allen abgesetzten Befehlen ausgegeben. Siehe auch Abschnitt E.1.2, „Trace-Dateien erzeugen“.

Wenn Sie andere Probleme mit den MySQL-Grant-Tabellen haben und diese der Mailingliste beschreiben wollen, fügen Sie auch immer einen Speicherauszug der MySQL-Grant-Tabellen bei. Diesen können Sie mit dem Befehl mysqldump mysql erstellen. Verwenden Sie zum Übermitteln eines Fehlerberichts die in Abschnitt 1.8, „Wie man Bugs oder Probleme meldet“ beschriebenen Anweisungen. In manchem Fällen müssen Sie mysqld unter Umständen mit der Option --skip-grant-tables neu starten, um mysqldump ausführen zu können.