Ein Access denied-Fehler kann viele Ursachen haben. Oft hängt er damit zusammen, welchen MySQL-Konten der Server die Benutzung von Clientprogrammen gestattet. Siehe Abschnitt 5.8.8, „Gründe für Access denied-Fehler“, und Abschnitt 5.8.2, „Wie das Berechtigungssystem funktioniert“.

Auf Unix hat ein MySQL-Client zwei Möglichkeiten, sich mit dem mysqld-Server zu verbinden: Entweder verwendet er eine Unix-Socketdatei (nach Voreinstellung /tmp/mysql.sock), um sich über eine Datei im Dateisystem zu verbinden, oder er verwendet TCP/IP, um sich über eine Portnummer zu verbinden. Eine Verbindung über eine Unix-Socketdatei ist schneller als TCP/IP, kann aber nur genutzt werden, wenn sich der Client mit einem Server auf demselben Computer verbindet. Der Weg über die Unix-Socketdatei wird gewählt, wenn Sie keinen Hostnamen oder localhost angeben.

Wenn der MySQL Server auf Windows 9x oder Me läuft, können Sie sich nur per TCP/IP verbinden. Wenn er auf Windows NT, 2000, XP oder 2003 läuft und mit der Option --enable-named-pipe gestartet wird, können Sie sich auch mit Named Pipes verbinden, wenn der Client auf demselben Host wie der Server läuft. Der Name der Named Pipe ist nach Voreinstellung MySQL. Wenn Sie für die Verbindung mit mysqld keinen Hostnamen angeben, versucht ein MySQL-Client als Erstes eine Verbindung mit der Named Pipe. Wenn das nicht klappt, verbindet er sich mit dem TCP/IP-Port. Indem Sie . als Hostnamen angeben, zwingen Sie Windows zur Verwendung von Named Pipes.

Der Fehler (2002) Can't connect to ... bedeutet normalerweise, dass auf dem System kein MySQL Server läuft oder dass Sie bei Ihrem Verbindungsversuch einen verkehrten Unix-Socketdateinamen oder TCP/IP-Port angegeben haben.

Prüfen Sie als Erstes, ob auf Ihrem Serverhost ein Prozess namens mysqld läuft. (Hierzu verwenden Sie auf Unix ps xa | grep mysqld und auf Windows den Task- Manager.) Wenn kein solcher Prozess läuft, starten Sie den Server. Siehe hierzu Abschnitt 2.9.2.3, „Probleme mit dem Start des MySQL Servers“.

Läuft ein mysqld-Server, so überprüfen Sie ihn mit den folgenden Befehlen. Die Portnummer oder der Name der Unix-Socketdatei können in Ihrem Fall abweichen. host_ip ist die IP-Nummer des Computers, auf welchem der Server ausgeführt wird.

shell> mysqladmin version
shell> mysqladmin variables
shell> mysqladmin -h `hostname` version variables
shell> mysqladmin -h `hostname` --port=3306 version
shell> mysqladmin -h host_ip version
shell> mysqladmin --protocol=socket --socket=/tmp/mysql.sock version

Beachten Sie, dass Backticks anstelle von Anführungszeichen für den hostname-Befehl verwendet werden. Diese sorgen dafür, dass die Ausgabe von hostname (also des aktuellen Hostnamens) in den Befehl mysqladmin eingesetzt wird. Wenn Sie keinen hostname-Befehl zur Verfügung haben oder mit Windows arbeiten, können Sie den Hostnamen Ihres Computers hinter der Option -h manuell eingeben (ohne Backticks). Oder Sie versuchen, sich mit -h 127.0.0.1 über TCP/IP mit dem lokalen Host zu verbinden.

Der Fehler Can't connect to local MySQL server könnte aus folgenden Gründen auftreten:

Wenn Sie die Fehlermeldung Can't connect to MySQL server on some_host bekommen, können Sie mit folgenden Mitteln herausfinden, wo das Problem liegt:

MySQL 5.1 verwendet ein Authentifizierungsprotokoll, das auf einem Passwort-Hash-Algorithmus basiert, der mit älteren Clients (vor Version 4.1) inkompatibel ist. Wenn Sie den Server von 4.1 auf die neue Version aufrüsten, können Verbindungsversuche mit einem älteren Client folgenden Fehler verursachen:

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

Für dieses Problem gibt es folgende Lösungsansätze:

Hinweis: In älteren PHP-Versionen unterstützt die mysql-Erweiterung nicht das Authentifizierungsprotokoll von MySQL 4.1.1 und höher. Das gilt unabhängig von der verwendeten PHP-Version. Wenn Sie die mysql-Erweiterung mit MySQL 4.1 oder höher nutzen möchten, müssen Sie unter Umständen einen der oben beschriebenen Wege einschlagen, um MySQL für ältere Clients zu konfigurieren. Die mysqli-Erweiterung (die in PHP 5 für "MySQL, Improved" steht) ist kompatibel mit dem verbesserten Passwort-Hashing von MySQL 4.1 und höher. Hier ist keine spezielle Konfiguration für MySQL erforderlich, um diese MySQL-Clientbibliothek nutzen zu können. Weitere Informationen über die mysqli-Erweiterung finden Sie unter http://php.net/mysqli.

Unter Umständen kann auch die ältere mysql-Erweiterung mit der neuen MySQL-Clientbibliothek kompiliert werden. Dieser Vorgang ist jedoch nicht Thema unseres Referenzhandbuchs. Weitere Informationen finden Sie in der PHP-Dokumentation. Eventuell können Sie in solchen Fragen auch im MySQL with PHP forum Hilfe finden.

Hintergrundinformationen über Passwort-Hashing und Authentifizierung gibt es unter Abschnitt 5.8.9, „Kennwort-Hashing ab MySQL 4.1“.

MySQL-Clientprogramme fordern zur Eingabe eines Passworts auf, wenn sie mit der Option --password oder -p ohne einen Passwortwert dahinter aufgerufen werden:

shell> mysql -u user_name -p
Enter password:

Auf manchen Systemen kann es vorkommen, dass das Passwort funktioniert, wenn man es in einer Optionsdatei oder auf der Kommandozeile angibt, aber nicht, wenn man es interaktiv am Enter password:-Prompt eintippt. Dies geschieht, wenn die Bibliothek, die das System zum Lesen von Passwörtern zur Verfügung stellt, die Passwortwerte auf eine geringe Zeichenzahl einschränkt (in der Regel 8 Zeichen). Dieses Problem betrifft nicht MySQL, sondern die Systembibliothek. Um es zu lösen, müssen Sie entweder Ihr MySQL-Passwort auf einen Wert kürzen, der nur 8 Zeichen lang ist, oder es in eine Optionsdatei setzen.

Wenn folgender Fehler gemeldet wird, bedeutet dies, dass mysqld vom Host 'host_name' viele Verbindungsanforderungen empfangen hat, die in der Mitte unterbrochen wurden:

Host 'host_name' is blocked because of many connection errors.
Unblock with 'mysqladmin flush-hosts'

Wie viele unterbrochene Anforderungen maximal zulässig sind, ist in der Systemvariablen max_connect_errors festgelegt. Nach max_connect_errors gescheiterten Anforderungen nimmt mysqld an, dass etwas nicht in Ordnung ist (beispielsweise ein Einbruchsversuch), und blockiert weitere Verbindungen dieses Hosts, bis Sie einen mysqladmin flush-hosts-Befehl oder eine FLUSH HOSTS-Anweisung geben. Siehe Abschnitt 5.2.2, „Server-Systemvariablen“.

Nach Voreinstellung blockiert mysqld einen Host nach 10 Verbindungsfehlern. Diesen Wert können Sie ändern, indem Sie den Server folgendermaßen starten:

shell> mysqld_safe --max_connect_errors=10000 &

Wenn Sie diese Fehlermeldung für einen Host bekommen, prüfen Sie als Erstes, ob mit den TCP/IP-Verbindungen von diesem Host alles in Ordnung ist. Bei Netzwerkproblemen nützt es nichts, den Wert der Variablen max_connect_errors heraufzusetzen.

Wenn Sie beim Versuch einer Verbindung mit dem mysqld-Server einen Too many connections-Fehler bekommen, so bedeutet dies, dass alle verfügbaren Verbindungen von anderen Clients belegt sind.

Die Systemvariable max_connections legt fest, wie viele Verbindungen zulässig sind. Ihr Standardwert ist 100. Wenn Sie mehr Verbindungen benötigen, müssen Sie mysqld mit einem größeren Wert für diese Variable neu starten.

mysqld erlaubt in Wirklichkeit max_connections+1 Clients eine Verbindung. Die eine zusätzliche Verbindung ist für Konten reserviert, die das SUPER-Recht haben. Indem Sie dieses Recht nur an Administratoren und nicht an normale Benutzer vergeben (diese benötigen es ohnehin nicht), kann sich ein Administrator selbst dann noch mit dem Server verbinden und mit der Anweisung SHOW PROCESSLIST eine Problemdiagnose vornehmen, wenn die Höchstzahl der unprivilegierten Clientverbindungen erreicht ist. Siehe Abschnitt 13.5.4.19, „SHOW PROCESSLIST“.

Wie viele Verbindungen MySQL maximal unterstützen kann, hängt von der Qualität der Thread-Bibliothek auf einer gegebenen Plattform ab. Linux oder Solaris müssten 500 bis 1.000 gleichzeitige Verbindungen dulden können, je nachdem, wie viel Arbeitsspeicher Sie haben und was Ihre Clients tun. Statische Linux-Binaries von MySQL AB können bis zu 4.000 Verbindungen unterstützen.

Wenn Sie mit dem Clientprogramm mysql eine Anfrage absetzen und einen Fehler wie den folgenden ernten, so bedeutet dies, dass mysql zu wenig Arbeitsspeicher hat, um das vollständige Abfrageergebnis zu speichern:

mysql: Out of memory at line 42, 'malloc.c'
mysql: needed 8136 byte (8k), memory in use: 12481367 bytes (12189k)
ERROR 2008: MySQL client ran out of memory

Dieses Problem beheben Sie, indem Sie zuerst prüfen, ob Ihre Anfrage korrekt ist. Ist es normal, dass sie so viele Zeilen zurückgibt? Wenn nicht, korrigieren Sie die Anfrage und versuchen es erneut. Andernfalls können Sie mysql mit der Option --quick aufrufen. Dann verwendet sie zum Abruf der Ergebnismenge die C-API-Funktion mysql_use_result(), die wesentlich weniger Last für den Client (aber mehr Last für den Server) bedeutet.

In diesem Abschnitt wird auch der hiermit verwandte Lost connection to server during query-Fehler behandelt.

Die häufigste Ursache eines MySQL server has gone away-Fehlers ist, dass der Server die Verbindung wegen eines Timeouts geschlossen hat. In diesem Fall wird normalerweise einer der folgenden Fehlercodes (je nach Betriebssystem) gemeldet:

Nach Voreinstellung schließt der Server die Verbindung, wenn nichts geschieht, nach acht Stunden. Dieses Zeitlimit können Sie in der Variablen wait_timeout ändern, wenn Sie mysqld starten. Siehe Abschnitt 5.2.2, „Server-Systemvariablen“.

Wenn Sie ein Skript verwenden, müssen Sie die Anfrage nur erneut absetzen, damit der Client sich automatisch erneut verbindet. Das setzt voraus, dass die automatische Neuverbindung im Client eingeschaltet ist (was beim mysql-Kommandozeilen-Client standardmäßig der Fall ist).

Oft kommen MySQL server has gone away-Fehler auch aus folgenden Gründen zustande:

Ob der MySQL Server abgestürzt und wieder hochgefahren ist, erfahren Sie, indem Sie mysqladmin version ausführen und auf die Uptime des Servers achten. Wenn die Clientverbindung unterbrochen war, weil mysqld abgestürzt und wieder hochgefahren ist, sollten Sie sich auf die Erforschung der Absturzursachen konzentrieren. Zuerst prüfen Sie, ob der Server bei derselben Anfrage erneut abstürzen wird. Siehe Abschnitt A.4.2, „Was zu tun ist, wenn MySQL andauernd abstürzt“.

Mehr Informationen über unterbrochene Verbindungen bekommen Sie, wenn Sie mysqld mit der Option --log-warnings=2 starten. Damit werden einige Verbindungsabbruchfehler in der Datei hostname.err protokolliert. Siehe Abschnitt 5.12.1, „Die Fehler-Logdatei“.

Wenn Sie einen Bugreport über dieses Problem schicken möchten, senden Sie uns bitte auch folgende Informationen:

Siehe auch Abschnitt A.2.10, „Kommunikationsfehler/abgebrochene Verbindung“, und Abschnitt 1.8, „Wie man Bugs oder Probleme meldet“.

Ein Kommunikationspaket ist eine einzelne an den MySQL Server geschickte SQL-Anweisung oder eine einzelne an den Client geschickte Zeile.

Das größtmögliche Paket, das von einem oder an einen MySQL 5.1 Server oder -Client übermittelt werden kann, ist 1 Gbyte groß.

Wenn ein MySQL-Client oder der mysqld-Server ein Paket empfängt, dessen Größe max_allowed_packet Bytes übersteigt, löst er einen Packet too large-Fehler aus und schließt die Verbindung. Manche Clients melden auch einen Lost connection to MySQL Server during query-Fehler, wenn das Kommunikationspaket zu groß ist.

Da Client und Server jeweils ihre eigene max_allowed_packet-Variable haben, müssen Sie diese auf beiden Seiten erhöhen, wenn Sie größere Pakete verschicken möchten.

Der Standardwert der max_allowed_packet-Variable des Clientprogramms mysql ist 16 Mbyte. Um ihn zu erhöhen, starten Sie mysql wie folgt:

mysql> mysql --max_allowed_packet=32M

So wächst die Paketgröße auf 32 MB.

Die maximale max_allowed_packet-Größe des Servers ist 1 MB. Sie können sie heraufsetzen, wenn der Server umfangreiche Anfragen verarbeiten muss (beispielsweise mit großen BLOB-Spalten). Um diese Variable auf 16 Mbytezu setzen, starten Sie den Server wie folgt:

mysql> mysqld --max_allowed_packet=16M

Sie können max_allowed_packet auch mit einer Optiondatei einstellen. Um beispielsweise die Paketgröße für den Server auf 16 Mbytezu setzen, fügen Sie einer Optionsdatei folgende Zeilen hinzu:

[mysqld]
max_allowed_packet=16M

Der Wert dieser Variablen lässt sich ohne Sicherheitsrisiko erhöhen, da der zusätzliche Speicher nur bei Bedarf zugewiesen wird. So weist beispielsweise mysqld nur dann mehr Speicher zu, wenn Sie eine lange Anfrage haben oder wenn mysqld eine große Ergebniszeile zurückgeben muss. Der kleine Standardwert dieser Variablen ist eine Vorsichtsmaßnahme, um unkorrekte Pakete zwischen Client und Server abzufangen und zu gewährleisten, dass Sie keine Speicherplatzprobleme bekommen, weil Sie versehentlich zu große Pakete verwenden.

Es können auch seltsame Dinge mit großen Paketen passieren, wenn Sie umfangreiche BLOB-Werte benutzen, aber mysqld zu wenig Speicher gegeben haben, um mit der Anfrage umzugehen. Wenn Sie den Verdacht haben, dass dies der Fall ist, müssen Sie ulimit -d 256000 am Anfang des mysqld_safe-Skripts hinzufügen und mysqld neu starten.

Das Fehlerlog des Servers kann wichtige Informationen über Verbindungsprobleme geben (siehe Abschnitt 5.12.1, „Die Fehler-Logdatei“). Wenn Sie den Server mit der Option --log-warnings starten, finden Sie im Fehlerlog vielleicht Meldungen wie diese:

010301 14:38:23  Aborted connection 854 to db: 'users' user: 'josh'

Wenn Aborted connections-Meldungen im Fehlerlog stehen, kann das folgende Ursachen haben:

Wenn so etwas geschieht, setzt der Server die Statusvariable Aborted_clients herauf.

Bei folgenden Vorfällen inkrementiert der Server die Statusvariable Aborted_connects:

Wenn diese Dinge passieren, kann das bedeuten, dass jemand versucht, in den Server einzudringen!

Andere Gründe für einen Abbruch von Clients oder Verbindungen können sein:

Siehe auch Abschnitt A.2.8, „MySQL server has gone away-Fehler“.

Ein Fehler wegen voller Tabelle kann aus mehreren Gründen auftreten:

Wenn Sie bei manchen Anfragen den folgenden Fehlertyp ernten, so bedeutet dies, dass MySQL keine temporäre Datei für die Ergebnismenge im temporären Verzeichnis anlegen kann:

Can't create/write to file '\\sqla3fe_0.ism'.

Dieser Fehler ist typisch für Windows; bei Unix sieht die Meldung ähnlich aus.

Eine Möglichkeit ist die, mysqld mit der Option --tmpdir zu starten oder sie in den Abschnitt [mysqld] Ihrer Optionsdatei zu schreiben. Um beispielsweise das Verzeichnis C:\temp vorzugeben, schreiben Sie:

[mysqld]
tmpdir=C:/temp

Das Verzeichnic C:\temp muss existieren und genügend Platz bieten, damit der MySQL Server hineinschreiben kann. Siehe Abschnitt 4.3.2, „my.cnf-Optionsdateien“.

Auch Berechtigungsprobleme können den Fehler verursachen. Achten Sie darauf, dass der MySQL Server in das tmpdir-Verzeichnis schreiben darf.

Schauen Sie auch auf den Fehlercode, den Ihnen perror liefert. Manchmal kann der Server nicht in eine Tabelle schreiben, weil das Dateisystem voll ist:

shell> perror 28
Error code  28:  No space left on device

Wenn Commands out of sync; you can't run this command now in Ihrem Clientcode gemeldet wird, rufen Sie Clientfunktionen in der verkehrten Reihenfolge auf.

Dies kann zum Beispiel geschehen, wenn Sie mysql_use_result() benutzen und versuchen, eine neue Anfrage auszuführen, ehe Sie mysql_free_result() aufgerufen haben. Oder wenn Sie versuchen, zwei Anfragen, die Daten liefern, auszuführen, ohne dazwischen mysql_use_result() oder mysql_store_result() aufzurufen.

Wenn Sie folgende Fehlermeldung sehen, so bedeutet dies, dass beim Starten von mysqld oder beim Neuladen der Berechtigungstabellen in der user-Tabelle ein Konto mit einem verkehrten Passwort gefunden wurde.

Found wrong password for user 'some_user'@'some_host'; ignoring user

Infolgedessen wird das Konto vom Berechtigungssystem einfach ignoriert.

Die folgende Liste zeigt mögliche Ursachen und Lösungen für dieses Problem auf:

Wenn Sie eine der folgenden Fehlermeldungen sehen, so bedeutet dies, dass in der voreingestellten Datenbank keine Tabelle mit dem gegebenen Namen existiert:

Table 'tbl_name' doesn't exist
Can't find file: 'tbl_name' (errno: 2)

In manchen Fällen ist die Tabelle zwar vorhanden, aber Sie sprechen sie nicht richtig an:

Der Befehl SHOW TABLES verrät Ihnen, welche Tabellen in Ihrer Datenbank vorliegen. Siehe Abschnitt 13.5.4, „SHOW“.

Bei Zeichensatzproblemen kann ein Fehler wie dieser auftreten:

MySQL Connection Failed: Can't initialize character set charset_name

Dieser Fehler kann folgende Gründe haben:

Wenn Sie den Fehler ERROR '...' not found (errno: 23), Can't open file: ... (errno: 24) oder einen anderen Fehler mit der errno 23 oder errno 24 von MySQL gemeldet bekommen, haben Sie nicht genügend Dateideskriptoren für den MySQL Server zugewiesen. Das Dienstprogramm perror verrät Ihnen, was welche Fehlernummer bedeutet:

shell> perror 23
Error code  23:  File table overflow
shell> perror 24
Error code  24:  Too many open files
shell> perror 11
Error code  11:  Resource temporarily unavailable

Das Problem hierbei ist, dass mysqld versucht, zu viele Dateien gleichzeitig geöffnet zu halten. Sie können entweder mysqld veranlassen, nicht so viele Dateien zugleich zu öffnen, oder die Anzahl der für mysqld verfügbaren Dateideskriptoren erhöhen.

Damit mysqld weniger Dateien zugleich offen behält, können Sie den Tabellen-Cache verkleinern, indem Sie den Wert der Systemvariablen table_open_cache heruntersetzen (ihr Standardwert ist 64). Wenn Sie die max_connections vermindern, vermindern Sie in einem auch die Anzahl der offenen Dateien (der Standardwert beträgt 100).

Die Anzahl der für mysqld verfügbaren Dateideskriptoren ändern Sie mit der Option --open-files-limit für mysqld_safe, oder Sie setzen (seit MySQL 3.23.30) die Systemvariable open_files_limit. Siehe Abschnitt 5.2.2, „Server-Systemvariablen“. Am einfachsten können Sie diese Werte ändern, indem Sie eine Option in Ihrer Optionsdatei einstellen. Siehe Abschnitt 4.3.2, „my.cnf-Optionsdateien“. Wenn Sie eine ältere Version von mysqld verwenden, in der sich die Höchstzahl der offenen Dateien nicht einstellen lässt, können Sie das Skript mysqld_safe bearbeiten. Dort gibt es eine auskommentierte Zeile mit dem Inhalt ulimit -n 256. Daraus entfernen Sie das Kommentarzeichen ‘#’ und stellen die Zahl 256 auf die Anzahl der gewünschten Dateideskriptoren um, die mysqld zur Verfügung stehen sollen.

--open-files-limit und ulimit können zwar die Anzahl der Dateideskriptoren erhöhen, aber nur bis zu dem Limit, das für Ihr Betriebssystem zulässig ist. Außerdem gibt es ein „hartes“ Limit, das nur überschrieben werden kann, wenn Sie mysqld_safe oder mysqld als root starten (denken Sie aber daran, in diesem Fall den Server mit der --user-Option zu starten, damit er nicht nach dem Hochfahren als root weiterläuft). Wenn Sie das Betriebssystemlimit für die Anzahl der Dateideskriptoren, die für jeden Prozess verfügbar sind, ändern möchten, müssen Sie in Ihre Systemdokumentation schauen.

Hinweis: Wenn Sie die tcsh-Shell ausführen, funktioniert ulimit nicht! Außerdem meldet tcsh verkehrte Werte, wenn Sie nach den aktuellen Limits fragen. In diesem Fall sollten Sie mysqld_safe mit sh starten.

Wenn Sie ein Anwendungsprogramm so verlinken, dass es die MySQL-Clientbibliothek benutzt, werden für Symbole, die mit mysql_ anfangen, undefined reference-Fehler gemeldet werden:

/tmp/ccFKsdPa.o: In function `main':
/tmp/ccFKsdPa.o(.text+0xb): undefined reference to `mysql_init'
/tmp/ccFKsdPa.o(.text+0x31): undefined reference to `mysql_real_connect'
/tmp/ccFKsdPa.o(.text+0x57): undefined reference to `mysql_real_connect'
/tmp/ccFKsdPa.o(.text+0x69): undefined reference to `mysql_error'
/tmp/ccFKsdPa.o(.text+0x9a): undefined reference to `mysql_close'

Um dieses Problem zu lösen, fügen Sie am Ende Ihres Link-Befehls -Ldir_path -lmysqlclient an, wobei dir_path den Pfadnamen des Verzeichnisses darstellt, in dem die Clientbibliothek liegt. Mit folgendem Befehl können Sie das richtige Verzeichnis herausfinden:

shell> mysql_config --libs

Die Ausgabe von mysql_config kann auch auf andere Bibliotheken hinweisen, die ebenfalls im Link-Befehl angegeben werden sollten.

Wenn undefined reference-Fehler für die Funktion uncompress oder compress gemeldet werden, fügen Sie am Ende des Link-Befehls -lz an und versuchen es erneut.

Treten undefined reference-Fehler im Zusammenhang mit einer Funktion auf, die auf Ihrem System existieren müsste, wie beispielsweise connect, sehen Sie auf der Handbuchseite zu dieser Funktion nach, um festzustellen, welche Bibliotheken Sie im Link-Befehl angeben müssen.

Wenn Funktionen auf Ihrem System nicht existieren, werden undefined reference-Fehler wie diese gemeldet:

mf_format.o(.text+0x201): undefined reference to `__lxstat'

Das bedeutet normalerweise, dass Ihre MySQL-Clientbibliothek auf einem System kompiliert wurde, das mit Ihrem nicht zu 100 % kompatibel ist. In diesem Fall sollten Sie die neueste MySQL-Quelldistribution herunterladen und MySQL selbst kompilieren. Siehe Abschnitt 2.8, „Installation der Quelldistribution“.

Zur Laufzeit können undefined reference-Fehler auftreten, wenn Sie versuchen, ein MySQL-Programm auszuführen. Wenn diese Fehler Symbole betreffen, die mit mysql_ anfangen oder anzeigen, dass die mysqlclient-Bibliothek nicht zu finden ist, so bedeutet dies, dass Ihr System die Shared Library libmysqlclient.so nicht finden kann. Dies beheben Sie, indem Sie Ihr System dort, wo sich die Bibliothek befindet, nach Shared Libraries suchen lassen. Aus den folgenden Verfahren können Sie das für Ihr System geeignete auswählen:

Sie können dieses Problem auch angehen, indem Sie Ihr Programm statisch mit der Option -static verlinken oder indem Sie die dynamischen MySQL-Bibliotheken entfernen, bevor Sie Ihren Code verlinken. Ehe Sie die zweite Methode wählen, müssen Sie sich vergewissern, dass keine anderen Programme die dynamischen Bibliotheken benutzen.

Wenn Sie Probleme mit Dateiberechtigungen haben, ist vielleicht die Umgebungsvariable UMASK beim Starten von mysqld falsch gesetzt. So könnte MySQL beispielsweise folgende Fehlermeldung ausgeben, wenn Sie eine Tabelle anlegen:

ERROR: Can't find file: 'path/with/filename.frm' (Errcode: 13)

Der Standardwert von UMASK ist 0660. Dies können Sie ändern, indem Sie mysqld_safe folgendermaßen starten:

shell> UMASK=384  # = 600 in octal
shell> export UMASK
shell> mysqld_safe &

Nach Voreinstellung legt MySQL Datenbanken und RAID-Verzeichnisse mit dem Zugriffsberechtigungswert 0700 an. Dies können Sie ändern, indem Sie die Variable UMASK_DIR einstellen. Wenn Sie ihren Standardwert ändern, werden neue Verzeichnisse mit einer Kombination der Werte UMASK und UMASK_DIR angelegt. Wenn Sie beispielsweise Gruppenzugriff für alle neuen Verzeichnisse festlegen möchten, gehen Sie folgendermaßen vor:

shell> UMASK_DIR=504  # = 770 in octal
shell> export UMASK_DIR
shell> mysqld_safe &

In der Version 3.23.25 und höher geht MySQL von einem Oktalwert für UMASK und UMASK_DIR aus, wenn der Wert mit einer Null beginnt.

Siehe Anhang F, Umgebungsvariablen.

Wenn Sie niemals ein root-Passwort für MySQL gesetzt haben, verlangt der Server überhaupt kein Passwort für eine root-Verbindung. Allerdings empfehlen wir Ihnen dringend, für jedes Konto ein Passwort einzurichten. Siehe Abschnitt 5.7.1, „Allgemeine Sicherheitsrichtlinien“.

Wenn Sie ein root-Passwort eingerichtet hatten, aber sich nicht mehr daran erinnern können, müssen Sie es neu einstellen. Die nachfolgende Anleitung ist auf Windows zugeschnitten; eine entsprechende Anleitung für Unix-Systeme finden Sie weiter unten in diesem Abschnitt.

Vorgehen unter Windows:

In einer Unix-Umgebung stellen Sie das root-Passwort folgendermaßen um:

Alternativ können Sie das neue Passwort auf jeder Plattform auch mit dem Client mysql einstellen (aber diese Methode ist nicht so sicher):

Jede MySQL-Version wird vor dem Release auf vielen Plattformen getestet. Dennoch kann es immer noch Bugs in MySQL geben, allerdings ziemlich wenige, die darüber hinaus schwer zu finden sind. Wenn Sie ein Problem haben, ist es immer gut, ganz genau festzustellen, was Ihr System zum Absturz brachte. Dann sind Ihre Chancen auf schnelle Abhilfe viel besser.

Als Erstes müssen Sie herausfinden, ob Ihr mysqld-Server oder Ihr Client an dem Absturz schuld ist. Der Befehl mysqladmin version verrät Ihnen, wie lange Ihr mysqld-Server bereits läuft. Wenn mysqld herunter- und wieder hochgefahren ist, finden Sie die Wurzel des Problems vielleicht im Fehlerlog des Servers. Siehe Abschnitt 5.12.1, „Die Fehler-Logdatei“.

Auf manchen Systemen enthält das Fehlerlog einen Stack-Trace mit der Information, wo mysqld abgestürzt ist. Diesen Trace können Sie mit dem Programm resolve_stack_dump auswerten. Siehe Abschnitt E.1.4, „Einen Stack-Trace benutzen“. Beachten Sie, dass die Variablenwerte im Fehlerlog nicht immer hundertprozentig korrekt sind.

Viele Serverabstürze werden durch beschädigte Daten- oder Indexdateien verursacht. MySQL aktualisiert nach jeder SQL-Anweisung und vor der Benachrichtigung des Clients über das Ergebnis die Dateien auf der Festplatte mit dem Systemaufruf write(). (Das gilt allerdings nicht, wenn Sie mit der Option --delay-key-write arbeiten: Hier werden zwar die Datendateien zeitnah geschrieben, aber nicht die Indexdateien.) Das bedeutet, dass der Inhalt der Datendateien selbst bei einem mysqld-Absturz sicher ist, weil das Betriebssystem dafür sorgt, dass die Arbeitsspeicherdaten auf die Platte zurückgeschrieben werden. Sie können MySQL zwingen, nach jeder SQL-Anweisung gleich alles auf die Platte zurückzuschreiben, indem Sie mysqld mit der Option --flush starten.

Das bedeutet, dass Sie normalerweise nur in folgenden Fällen mit beschädigten Tabellen zu tun haben:

Da der Grund für einen Absturz so schwer festzustellen ist, sollten Sie zuerst versuchen, herauszufinden, ob Dinge, die bei anderen funktionieren, bei Ihnen abstürzen. Hierzu sollten Sie Folgendes ausprobieren:

Dieser Abschnitt beschreibt, wie MySQL mit Fehlern umgeht, die aufgrund einer vollen Festplatte auftreten (wie beispielsweise „no space left on device“), und wie Fehler aufgrund von Kontingentüberschreitung behandelt werden (wie zum Beispiel „write failed“ oder „user block limit reached“).

Dieser Abschnitt ist für Schreiboperationen auf MyISAM-Tabellen relevant. Er gilt jedoch auch für Schreiboperationen in Binärlogdateien und die Binärlog-Indexdatei, nur dass die Begriffe „row“ und „record“ im Zusammenhang mit Logs „Ereignisse“ bedeuten.

Wenn ein Fehler wegen voller Festplatte auftritt, geht MySQL wie folgt vor:

Dieses Problem können Sie folgendermaßen beheben:

Das oben geschilderte Verhalten tritt nicht ein, wenn Sie REPAIR TABLE oder OPTIMIZE TABLE gesagt haben oder wenn die Indizes nach LOAD DATA INFILE oder nach einer ALTER TABLE-Anweisung in Stapelverarbeitung erstellt werden. Alle diese Anweisungen können große temporäre Dateien erzeugen, die den Rest des Systems in Schwierigkeiten bringen, wenn sie sich selbst überlassen bleiben. Wenn die Platte voll läuft, während MySQL eine dieser Operationen ausführt, löscht MySQL eine der großen temporären Dateien und kennzeichnet die Tabelle als abgestürzt. Ausnahme: Bei ALTER TABLE bleibt die alte Tabelle unverändert.

MySQL verwendet den Wert der Umgebungsvariablen TMPDIR als Pfad zu dem Verzeichnis, in dem die temporären Dateien gespeichert werden. Wenn Sie TMPDIR nicht eingestellt haben, benutzt MySQL den systemeigenen Standardwert, also normalerweise /tmp, /var/tmp oder /usr/tmp. Wenn das Dateisystem, in dem Ihr Verzeichnis für temporäre Dateien liegt, zu klein ist, können Sie mit der Option --tmpdir von mysqld ein anderes Verzeichnis in einem ausreichend großen Dateisystem einstellen.

In MySQL 5.1 kann die Option --tmpdir auf eine Liste mit mehreren Pfaden eingestellt werden, die dann im Ringverfahren (jeder kommt einmal dran) benutzt werden. Die Pfade sollten auf Unix durch Doppelpunkte (‘:’) getrennt werden, und auf Windows, NetWare und OS/2 durch Semikola (‘;’). Hinweis: Um die Last wirkungsvoll zu verteilen, sollten diese Pfade zu verschiedenen physikalischen Platten und nicht nur zu verschiedenen Partitionen derselben Festplatte führen.

Wenn der MySQL Server ein Replikationsslave ist, sollten Sie die Option --tmpdir nicht auf ein Verzeichnis in einem arbeitsspeicherbasierten Dateisystem oder auf ein anderes Verzeichnis einstellen, das beim Neustart des Serverhosts gelöscht wird. Ein Replikationsslave benötigt einige seiner temporären Dateien, um einen Neustart des Computers so zu überleben, dass er temporäre Tabellen oder LOAD DATA INFILE-Operationen replizieren kann. Wenn Dateien aus dem temporären Verzeichnis beim Neustart des Servers verloren gehen, scheitert die Replikation.

MySQL legt alle temporären Dateien als verborgene Dateien an. Das soll gewährleisten, dass die temporären Dateien beim Herunterfahren von mysqld entfernt werden. Allerdings haben verborgene Dateien den Nachteil, dass eine große temporäre Datei, die das Dateisystem überlastet, in welchem das temporäre Verzeichnis liegt, nicht zu sehen ist.

Bei Sortieroperationen (ORDER BY oder GROUP BY) verwendet MySQL normalerweise ein oder zwei temporäre Dateien. Wie viel Platz auf der Festplatte dafür maximal notwendig ist, verrät Ihnen der folgende Ausdruck:

(Länge der Daten + sizeof(Zeilenzeiger))
* Anzahl der gefundenen Zeilen
* 2

Der Zeilenzeiger ist normalerweise 4 Byte groß, kann aber bei sehr großen Tabellen in Zukunft noch wachsen.

Für manche SELECT-Anfragen legt MySQL ebenfalls temporäre SQL-Tabellen an. Diese sind nicht verborgen und haben Namen der Form SQL_*.

ALTER TABLE legt eine temporäre Tabelle in dem Verzeichnis der Originaltabelle an.

Die Unix-Socketdatei, die der Server für die Kommunikation mit lokalen Clients benötigt, liegt nach Voreinstellung unter /tmp/mysql.sock. (In manchen Distributionsformaten kann es auch ein anderes Verzeichnis sein, wie beispielsweise /var/lib/mysql für RPMs.)

Auf manchen Unix-Versionen kann jeder Dateien aus dem Verzeichnis /tmp oder anderen ähnlichen Verzeichnissen für temporäre Dateien löschen. Wenn die Socketdatei auf Ihrem Dateisystem in einem solchen Verzeichnis liegt, kann das zu Problemen führen.

Auf den meisten Unix-Versionen können Sie Ihr /tmp-Verzeichnis schützen, sodass die Dateien nur von ihren Eigentümern oder dem Superuser (root) gelöscht werden können. Hierzu setzen Sie das sticky-Bit auf dem /tmp-Verzeichnis, indem Sie sich als root anmelden und folgenden Befehl geben:

shell> chmod +t /tmp

Ob das sticky-Bit gesetzt wurde, prüfen Sie mit ls -ld /tmp. Wenn das letzte Zeichen der Berechtigung ein t ist, wurde das Bit gesetzt.

Sie können auch veranlassen, dass der Server die Unix-Socketdatei in einem anderen Verzeichnis erstellt. Wenn Sie dies tun, müssen Sie den Clientprogrammen auch verraten, wo diese Datei jetzt liegt. Den Speicherort können Sie auf mehrere Weisen angeben:

Ob der neue Socketspeicherort funktioniert, können Sie überprüfen, indem Sie mit folgendem Befehl eine Serververbindung herstellen:

shell> mysqladmin --socket=/path/to/socket version

Wenn Sie das Problem haben, dass SELECT NOW() Werte in UTC anstelle Ihrer Ortszeit liefert, müssen Sie Ihren Server auf Ihre Zeitzone einstellen. Dasselbe gilt, wenn UNIX_TIMESTAMP() den verkehrten Wert zurückgibt. Dies sollte für die Umgebung veranlasst werden, in welcher der Server läuft, also zum Beispiel in mysqld_safe oder mysql.server. Siehe Anhang F, Umgebungsvariablen.

Die Zeitzone für den Server stellen Sie mit der Option --timezone=timezone_name von mysqld_safe ein. Alternativ können Sie die Umgebungsvariable TZ einstellen, bevor Sie mysqld starten.

Die zulässigen Werte für --timezone oder TZ hängen vom System ab. Bitte schlagen Sie in der Dokumentation Ihres Betriebssystems die jeweils passenden Werte nach.

Nach Voreinstellung unterscheiden Suchoperationen in MySQL nicht zwischen Groß- und Kleinschreibung (wobei allerdings manche Zeichensätze grundsätzlich immer zwischen Groß- und Kleinschreibung unterscheiden, wie beispielsweise czech). Das bedeutet, dass Sie bei einer Suche mit col_name LIKE 'a%' alle Spaltenwerte geliefert bekommen, die mit A oder a anfangen. Wenn Sie diese Suche auf Groß- oder Kleinbuchstaben einschränken möchten, müssen Sie dafür sorgen, dass die Kollation eines der beiden Operanden Groß- und Kleinschreibung unterscheidet oder eine Binärkollation ist. Wenn Sie beispielsweise eine Spalte und einen String vergleichen, die beide den Zeichensatz latin1 verwenden, können Sie den COLLATE-Operator einschalten, um einem der beiden Operanden die Kollation latin1_general_cs oder latin1_bin zuzuweisen. Zum Beispiel:

col_name COLLATE latin1_general_cs LIKE 'a%'
col_name LIKE 'a%' COLLATE latin1_general_cs
col_name COLLATE latin1_bin LIKE 'a%'
col_name LIKE 'a%' COLLATE latin1_bin

Wenn Sie in einer Spalte immer die Groß- und Kleinschreibung berücksichtigen möchten, deklarieren Sie sie mit einer Binärkollation oder CS-Kollation (CS steht für die Unterscheidung von Groß- und Kleinschreibung). Siehe Abschnitt 13.1.5, „CREATE TABLE“.

Einfache Vergleichsoperationen (>=, >, =, <, <=, Sortieren und Gruppieren) beruhen auf dem „Sortierwert“ der Zeichen. Zeichen mit demselben Sortierwert (wie etwa ‘E’, ‘e’ und ‘é’) werden als gleich betrachtet.

Das Format eines DATE-Werts ist 'YYYY-MM-DD'. Im Standard-SQL ist kein anderes Format erlaubt. Dieses Format muss in UPDATE-Ausdrücken und in der WHERE-Klausel von SELECT-Anweisungen immer verwendet werden. Zum Beispiel:

mysql> SELECT * FROM tbl_name WHERE date >= '2003-05-05';

Der Bequemlichkeit halber konvertiert MySQL ein Datum, das in einem numerischen Kontext benutzt wird, automatisch in eine Zahl (und umgekehrt). MySQL ist auch clever genug, um bei Updates und in einer WHERE-Klausel, die ein Datum mit einer TIMESTAMP-, DATE- oder DATETIME-Spalte vergleicht, eine „lockere“-String-Form zuzulassen. („Lockere Form“ bedeutet, dass zwischen den einzelnen Teilen jedes Interpunktionszeichen als Trennzeichen zulässig ist. So sind zum Beispiel '2004-08-15' und '2004#08#15' äquivalent.) MySQL kann auch einen String, der keine Trennzeichen enthält (wie etwa '20040815') konvertieren, vorausgesetzt, er ergibt einen vernünftigen Datumswert.

Wenn Sie Werte vom Typ DATE, TIME, DATETIME oder TIMESTAMP mit einem konstanten String vergleichen, der die Operatoren <, <=, =, >=, > oder BETWEEN enthält, konvertiert MySQL den String normalerweise intern in einen langen Integer, um Vergleiche schneller ausführen zu können (und ein wenig „locker“ bei der String-Prüfung sein zu können). Von dieser Konvertierung gibt es allerdings folgende Ausnahmen:

In diesen Ausnahmefällen führt MySQL den Vergleich durch, indem es die Objekte in Strings konvertiert und dann die Strings vergleicht.

Um sicherzugehen, sollten Sie davon ausgehen, dass Strings als Strings verglichen werden, und die passenden Funktionen einsetzen, wenn Sie einen Temporalwert mit einem String vergleichen möchten.

Das spezielle Datum '0000-00-00' kann als '0000-00-00' gespeichert und abgerufen werden. Wenn Sie ein '0000-00-00'-Datum in MyODBC benutzen, so wird es in MyODBC 2.50.12 und höher automatisch in NULL konvertiert, da ODBC mit Datumswerten dieser Art nicht umgehen kann.

Da MySQL die oben beschriebenen Konvertierungen vornimmt, funktionieren folgende Anweisungen:

mysql> INSERT INTO tbl_name (idate) VALUES (19970505);
mysql> INSERT INTO tbl_name (idate) VALUES ('19970505');
mysql> INSERT INTO tbl_name (idate) VALUES ('97-05-05');
mysql> INSERT INTO tbl_name (idate) VALUES ('1997.05.05');
mysql> INSERT INTO tbl_name (idate) VALUES ('1997 05 05');
mysql> INSERT INTO tbl_name (idate) VALUES ('0000-00-00');

mysql> SELECT idate FROM tbl_name WHERE idate >= '1997-05-05';
mysql> SELECT idate FROM tbl_name WHERE idate >= 19970505;
mysql> SELECT MOD(idate,100) FROM tbl_name WHERE idate >= 19970505;
mysql> SELECT idate FROM tbl_name WHERE idate >= '19970505';

Doch die folgende Anweisung funktioniert nicht:

mysql> SELECT idate FROM tbl_name WHERE STRCMP(idate,'20030505')=0;

Da STRCMP() eine String-Funktion ist, konvertiert sie idate in einen String im Format 'YYYY-MM-DD' und führt einen String-Vergleich durch. '20030505' wird nicht in das Datum '2003-05-05' konvertiert, um einen Datumsvergleich durchzuführen.

Wenn Sie den SQL-Modus ALLOW_INVALID_DATES eingestellt haben, gestattet MySQL Ihnen die Speicherung von Datumswerten bei nur rudimentärer Überprüfung: MySQL verlangt lediglich, dass der Tag im Bereich von 1 bis 31 und der Monat im Bereich von 1 bis 12 liegt.

Dadurch eignet sich MySQL gut für Webanwendungen, bei denen Jahr, Monat und Tag in drei verschiedenen Feldern abgerufen werden und in denen Sie genau das, was der Benutzer eingibt, speichern möchten (ohne das Datum zu validieren).

Wenn Sie nicht den SQL-Modus NO_ZERO_IN_DATE SQL verwenden, kann der Tag oder der Monat null sein. Das ist praktisch, wenn Sie in einer DATE-Spalte einen Geburtstag speichern möchten, dessen Datum Sie nur teilweise kennen.

Wenn Sie nicht den SQL-Modus NO_ZERO_DATE verwenden, gestattet Ihnen MySQL auch, '0000-00-00' als „Dummy-Datum“ zu speichern. Das ist manchmal praktischer als NULL-Werte.

Wenn sich das Datum nicht in einen vernünftigen Wert konvertieren lässt, wird eine 0 in der DATE-Spalte gespeichert und als '0000-00-00' abgerufen. Dies ist eine Frage von Schnelligkeit und Bequemlichkeit. Wir sind der Ansicht, dass der Datenbankserver dieselben Daten liefern sollte, die gespeichert wurden (selbst wenn diese Daten im Einzelfall nicht immer logisch richtig sind). Wir denken, dass es Sache der Anwendung ist, die Datumswerte zu überprüfen.

Wenn Sie wollen, dass MySQL die Daten überprüft und nur gültige zulässt (es sei denn, dies wird durch IGNORE außer Kraft gesetzt), müssen Sie den sql_mode auf "NO_ZERO_IN_DATE,NO_ZERO_DATE" einstellen.

NULL-Werte stiften bei SQL-Neulingen immer wieder Verwirrung, da diese oft denken, NULL sei dasselbe wie der leere String ''. Doch das ist nicht der Fall. Die folgenden Anweisungen sind beispielsweise völlig verschieden:

mysql> INSERT INTO my_table (phone) VALUES (NULL);
mysql> INSERT INTO my_table (phone) VALUES ('');

Beide Anweisungen fügen einen Wert in die phone-Spalte ein, die erste allerdings einen NULL-Wert und die zweite einen leeren String. Die erste Eingabe bedeutet so viel wie „Telefonnummer unbekannt“ und die zweite bedeutet „Die Person hat kein Telefon und somit keine Telefonnummer“.

Als Hilfe für den Umgang mit NULL-Werten sind die Operatoren IS NULL und IS NOT NULL sowie die Funktion IFNULL() da.

In SQL ergibt ein Vergleich zwischen NULL und irgendeinem anderen Wert nie einen Treffer, selbst wenn auch der andere Wert NULL ist. Ein Ausdruck, der NULL enthält, ergibt immer den Wert NULL, es sei denn, die Dokumentation der Operatoren und Funktionen, die an dem Ausdruck beteiligt sind, sagt ausdrücklich etwas anderes. Alle Spalten im folgenden Beispiel geben NULL zurück:

mysql> SELECT NULL, 1+NULL, CONCAT('Invisible',NULL);

Wenn Sie Spaltenwerte suchen, die NULL sind, verwenden Sie bitte nicht den Test expr = NULL. Die folgende Anweisung gibt gar keine Zeilen zurück, da expr = NULL niemals wahr sein kann:

mysql> SELECT * FROM my_table WHERE phone = NULL;

Wenn Sie NULL-Werte suchen, dann mit IS NULL. Die folgenden Anweisungen zeigen, wie man die Telefonnummer NULL und die leere Telefonnummer finden kann:

mysql> SELECT * FROM my_table WHERE phone IS NULL;
mysql> SELECT * FROM my_table WHERE phone = '';

Weitere Informationen und Beispiele finden Sie unter Abschnitt 3.3.4.6, „Mit NULL-Werten arbeiten“.

Sie können einer Spalte, die NULL-Werte enthält, einen Index hinzufügen, wenn Sie MyISAM, InnoDB, BDB oder MEMORY als Speicher-Engine einsetzen. Andernfalls müssen Sie die indizierte Spalte als NOT NULL deklarieren und können keine NULL-Werte in sie einfügen.

Wenn Sie Daten mit LOAD DATA INFILE lesen, werden leere oder fehlende Spalten mit '' aktualisiert. Möchten Sie in eine Spalte einen NULL-Wert einfügen, so müssen Sie \N in die Datendatei schreiben. Das Literal „NULL“ kann unter bestimmten Umständen ebenfalls verwendet werden. Siehe Abschnitt 13.2.5, „LOAD DATA INFILE“.

DISTINCT, GROUP BY oder ORDER BY betrachten alle NULL-Werte als gleich.

ORDER BY stellt die NULL-Werte immer an den Anfang oder, wenn DESC für eine absteigende Sortierreihenfolge angegeben wurde, an das Ende.

Aggregatfunktionen (Summenfunktionen) wie COUNT(), MIN() und SUM() ignorieren NULL-Werte. Eine Ausnahme bildet die Funktion COUNT(*), die Zeilen und nicht einzelne Spaltenwerte zählt. Die folgende Anweisung erstellt beispielsweise zwei Zählungen: eine Zählung der Zeilen in der Tabelle und eine Zählung der von NULL verschiedenen Werte in der Spalte age:

mysql> SELECT COUNT(*), COUNT(age) FROM person;

Für manche Datentypen behandelt MySQL NULL-Werte ganz speziell. Wenn Sie NULL in eine TIMESTAMP-Spalte einfügen, werden Datum und Uhrzeit von jetzt eingefügt. Wenn Sie NULL in eine Integer-Spalte einfügen, die das AUTO_INCREMENT-Attribut hat, wird stattdessen die nächste Folgenummer eingesetzt.

Einen Alias können Sie verwenden, um eine Spalte in GROUP BY-, ORDER BY- oder HAVING-Klauseln zu benennen. Außerdem sind Aliasnamen nützlich, um Spalten bessere Namen zu verpassen:

SELECT SQRT(a*b) AS root FROM tbl_name GROUP BY root HAVING root > 0;
SELECT id, COUNT(*) AS cnt FROM tbl_name GROUP BY id HAVING cnt > 0;
SELECT id AS 'Customer identity' FROM tbl_name;

Im Standard-SQL dürfen Sie in WHERE-Klauseln keine Spaltenaliase benutzen, da der Spaltenwert unter Umständen noch gar nicht festliegt, wenn der WHERE-Code ausgeführt wird. Die folgende Anfrage ist beispielsweise unzulässig:

SELECT id, COUNT(*) AS cnt FROM tbl_name WHERE cnt > 0 GROUP BY id;

Die WHERE-Anweisung soll festlegen, welche Zeilen in den GROUP BY-Teil einfließen, während die HAVING-Klausel entscheiden soll, welche Zeilen der Ergebnismenge benutzt werden sollen.

Wenn Sie die folgende Meldung beim Versuch eines ROLLBACK erhalten, so bedeutet dies, dass mindestens eine in der Transaktion verwendete Tabelle gar keine Transaktionen unterstützt:

Änderungen an einigen nicht transaktionalen Tabellen konnten nicht zurückgerollt werden

Diese nichttransaktionssicheren Tabellen werden von der ROLLBACK-Anweisung gar nicht betroffen.

Wenn Sie nicht absichtlich transaktionssichere und nichttransaktionssichere Tabellen in der Transaktion mischen, tritt diese Fehlermeldung wahrscheinlich auf, weil eine Tabelle, die Sie für transaktionssicher gehalten haben, dies in Wirklichkeit nicht ist. Das kann passieren, wenn Sie eine Tabelle mit einer transaktionssicheren Speicher-Engine anlegen, die nicht von Ihrem mysqld-Server unterstützt wird (oder mit einer Startoption ausgeschaltet wurde). Wenn mysqld eine Speicher-Engine nicht unterstützt, wird eine MyISAM-Tabelle angelegt, und diese ist nicht transaktionssicher.

Welche Speicher Engine eine Tabelle verwendet, erfahren Sie mit folgenden Anweisungen:

SHOW TABLE STATUS LIKE 'tbl_name';
SHOW CREATE TABLE tbl_name;

Siehe Abschnitt 13.5.4.21, „SHOW TABLE STATUS“, und Abschnitt 13.5.4.6, „SHOW CREATE TABLE“.

Welche Speicher-Engines Ihr mysqld-Server verwendet, finden Sie mit dieser Anweisung heraus:

SHOW ENGINES;

Sie können jedoch auch nachfolgende Anweisung ausführen und den Wert der Variablen betrachten, die für die von Ihnen gewünschte Speicher-Engine steht:

SHOW VARIABLES LIKE 'have_%';

Um beispielsweise festzustellen, ob die Speicher-Engine InnoDB zur Verfügung steht, schauen Sie auf den Wert der Variablen have_innodb.

Siehe Abschnitt 13.5.4.9, „SHOW ENGINES“, und Abschnitt 13.5.4.24, „SHOW VARIABLES“.

Wenn die DELETE-Anweisung für related_table insgesamt mehr als 1 Mbyte beträgt (der Standardwert der Systemvariablen max_allowed_packet), dann müssen Sie sie aufteilen und als mehrere kleinere DELETE-Anweisungen ausführen. Am schnellsten läuft ein DELETE, wenn Sie nur 100 bis 1.000 related_column-Werte pro (indizierter) Anweisung angeben. Wenn related_column keinen Index hat, ist die Geschwindigkeit von der Anzahl der Argumente der IN-Klausel unabhängig.

Wenn Sie eine komplizierte Anfrage ausführen, die viele Tabellen benutzt, aber nichts zurückgibt, können Sie mit folgendem Verfahren herausfinden, was schief gegangen ist:

Der folgende Abschnitt ist vor allem für DOUBLE- und FLOAT-Spalten interessant, da Fließkommazahlen von Natur aus ungenau sind. MySQL führt DECIMAL-Operationen mit einer Genauigkeit von 64 Dezimalstellen aus. Das müsste die meisten Probleme im Hinblick auf die Genauigkeit von DECIMAL-Spalten lösen.

Fließkommazahlen stiften gelegentlich Verwirrung, da sie in einer Computerarchitektur nicht als exakte Werte gespeichert werden. Das, was der Bildschirm zeigt, ist in der Regel nicht der genaue Wert der Zahl. Die Datentypen FLOAT und DOUBLE sind Fließkommatypen. DECIMAL-Spalten speichern Werte mit einer exakten Anzahl Stellen, weil sie als Strings dargestellt werden.

Das folgende Beispiel verdeutlicht das Problem an einem DOUBLE:

mysql> CREATE TABLE t1 (i INT, d1 DOUBLE, d2 DOUBLE);
mysql> INSERT INTO t1 VALUES (1, 101.40, 21.40), (1, -80.00, 0.00),
    -> (2, 0.00, 0.00), (2, -13.20, 0.00), (2, 59.60, 46.40),
    -> (2, 30.40, 30.40), (3, 37.00, 7.40), (3, -29.60, 0.00),
    -> (4, 60.00, 15.40), (4, -10.60, 0.00), (4, -34.00, 0.00),
    -> (5, 33.00, 0.00), (5, -25.80, 0.00), (5, 0.00, 7.20),
    -> (6, 0.00, 0.00), (6, -51.40, 0.00);

mysql> SELECT i, SUM(d1) AS a, SUM(d2) AS b
    -> FROM t1 GROUP BY i HAVING a <> b;

+------+-------+------+
| i    | a     | b    |
+------+-------+------+
|    1 |  21.4 | 21.4 |
|    2 |  76.8 | 76.8 |
|    3 |   7.4 |  7.4 |
|    4 |  15.4 | 15.4 |
|    5 |   7.2 |  7.2 |
|    6 | -51.4 |    0 |
+------+-------+------+

Das Ergebnis ist richtig. Auch wenn die ersten fünf Datensätze nicht so aussehen, als würden sie den Test bestehen (die Werte von a und b sehen nicht verschieden aus), können sie dennoch unterschiedlich sein, da sie womöglich in der zehnten Nachkommastelle oder so (je nach Computerarchitektur) eine Abweichung aufweisen.

Wären die Spalten d1 und d2 als DECIMAL statt als DOUBLE definiert, so hätte die SELECT-Anfrage nur eine einzige Zeile geliefert, nämlich die letzte der obigen Tabelle.

ALTER TABLE stellt die Tabelle auf den aktuellen Zeichensatz um. Wenn Sie während der Ausführung von ALTER TABLE einen Fehler wegen doppelt vorhandener Schlüssel bekommen, liegt dies entweder daran, dass der neue Zeichensatz zwei Schlüssel demselben Wert zuordnet, oder daran, dass die Tabelle beschädigt ist. Im zweiten Fall müssen Sie eine REPAIR TABLE-Anweisung auf der Tabelle ausführen.

Wenn ALTER TABLE mit der folgenden Fehlermeldung abbricht, kann dies daran liegen, dass MySQL bei einer vorherigen ALTER TABLE-Operation abgestürzt ist und noch eine alte Tabelle namens A-xxx oder B-xxx in der Gegend herumfliegt:

Error on rename of './database/name.frm'
to './database/B-xxx.frm' (Errcode: 17)

In diesem Fall gehen Sie in das Data Directory von MySQL und löschen alle Dateien, deren Namen mit A- oder B- anfangen. (Oder Sie verschieben sie an einen anderen Ort, anstatt sie zu löschen).

ALTER TABLE funktioniert folgendermaßen:

Wenn bei der Umbenennungsoperation etwas schief geht, versucht MySQL, die Änderungen rückgängig zu machen. Bei ernsthaften Problemen (die eigentlich nicht vorkommen sollten) könnte MySQL die alte Tabelle als B-xxx zurücklassen. Mit einer einfachen Umbenennung der Tabellendateien auf Systemebene müssten Sie Ihre Daten zurückbekommen.

Wenn Sie ALTER TABLE auf einer transaktionssicheren Tabelle ausführen oder Windows oder OS/2 benutzen, wird ALTER TABLE eine Sperre der Tabelle aufheben, falls Sie zuvor eine LOCK TABLE-Anweisung auf ihr ausgeführt haben, da InnoDB und diese Betriebssysteme keine Tabelle löschen können, die gerade in Gebrauch ist.

Zuerst müssen Sie überlegen, ob es wirklich notwendig ist, die Spaltenreihenfolge in der Tabelle zu ändern. Das Hauptanliegen von SQL ist ja schließlich, die Anwendung vom Format der Datenspeicherung abzukoppeln. Sie sollten immer die Reihenfolge angeben, in der Sie Ihre Daten abholen möchten. Die erste der folgenden Anweisungen gibt die Spalten in der Reihenfolge col_name1, col_name2, col_name3 zurück, und die zweite in der Reihenfolge col_name1, col_name3, col_name2:

mysql> SELECT col_name1, col_name2, col_name3 FROM tbl_name;
mysql> SELECT col_name1, col_name3, col_name2 FROM tbl_name;

Wenn Sie dennoch die Reihenfolge der Spalten ändern möchten, tun Sie das folgendermaßen:

SELECT * eignet sich gut für Testanfragen. In einer Anwendung sollten Sie sich jedoch nie darauf verlassen, mit SELECT * die Spalten nach ihrer Position abzufragen. Die Reihenfolge und Position, in der die Spalten zurückgegeben werden, kann sich ändern, wenn Sie Spalten neu einfügen, verschieben oder löschen. Eine einfache Änderung an der Tabellenstruktur kann so Ihre Anwendung bereits zum Absturz bringen.

Für die Nutzung von TEMPORARY-Tabellen gibt es folgende Beschränkungen:

Die folgenden Probleme sind bekannt und werden vorrangig gelöst:

Die folgenden Probleme sind bekannt und werden bald behoben: