:: DEVELOPER ZONE
Die folgenden Probleme sind bekannt. Ihre Behebung hat eine sehr hohe Priorität:
ANALYZE TABLE kann eine BDB-Tabelle in manchen Fällen unbenutzbar
machen, bis mysqld neu gestartet wird. Wenn so etwas passiert,
stehen Fehlermeldungen wie die folgende in der MySQL-Fehler-Datei (Error
File):
001207 22:07:56 bdb: log_flush: LSN past current end-of-log
Führen Sie mit einer BDB-Tabelle nicht ALTER TABLE aus, wenn
Sie mit dieser noch nicht abgeschlossene Mehrfach-Statement-Transaktionen
durchführen. (Die Transaktion wird wahrscheinlich ignoriert.)
ANALYZE TABLE, OPTIMIZE TABLE und REPAIR TABLE können
Probleme bei Tabellen verursachen, für die INSERT DELAYED benutzt
wird.
Wenn Sie LOCK TABLE .. und FLUSH TABLES .. benutzen, können
Sie nicht sicher sein, dass bei der fraglichen Tabelle keine halb
abgeschlossenen Transaktionen im Gange sind.
BDB-Tabellen lassen sich etwas langsam öffnen. Wenn Sie viele BDB-Tabellen
in einer Datenbank haben, kann es sehr lange dauern, bis Sie den
mysql-Client für diese Datenbank benutzen können, wenn Sie die
-A-Option oder rehash benutzen. Das macht sich speziell dann
bemerkbar, wenn Sie einen große Tabellen-Cache benutzen.
Das momentane Replikationsprotokoll kann nicht mit LOAD DATA INFILE
und mit Zeilenbegrenzungszeichen (line terminator characters) umgehen, die
mehr als 1 Zeichen enthalten.
Folgende Probleme sind bekannt und werden zu gegebener Zeit behoben:
Momentan funktioniert MATCH nur bei SELECT-Statements.
Wenn Sie SET CHARACTER SET benutzen, können Sie keine
landesspezifischen (nationalen) Zeichen für Datenbank-, Tabellen- und
Spaltennamen verwenden (also z. B. kein ä, ö, ü).
DELETE FROM merge_table ohne WHERE löscht nur die Zuordnung
(das Mapping) für die Tabelle, nicht alles in der zugeordneten (gemappten)
Tabelle.
Sie können den Server nicht in ein anderes Verzeichnis bauen, wenn Sie MIT-Pthreads verwenden. Weil dies Änderungen an MIT-Pthreads bedingen würde, werden wir dieses Problem wahrscheinlich nicht beheben.
BLOB-Werte können nicht ``zuverlässig'' in GROUP BY-,
ORDER BY oder DISTINCT-Klauseln benutzt werden. In diesen
Fällen werden bei Vergleichen nur die ersten max_sort_length
Bytes (Vorgabewert 1024) von BLOBs benutzt. Die Voreinstellung kann
mit der -O max_sort_length-Option für mysqld geändert werden.
In den meisten Fällen können Sie als Workaround eine Teilzeichenkette
(Substring) verwenden: SELECT DISTINCT LEFT(blob,2048) FROM tabelle.
Berechnungen werden mit BIGINT oder DOUBLE durchgeführt
(beide sind normalerweise 64 Bits lang). Es hängt von der verwendeten
Funktion ab, welche Genauigkeit man erhält. Als allgemeine Regel gilt, dass
Bit-Funktionen mit BIGINT-Genauigkeit, IF und ELT()
mit BIGINT- oder DOUBLE-Genauigkeit und der Rest mit
DOUBLE-Genauigkeit durchgeführt werden. Man sollte vermeiden,
vorzeichenlose Werte, die größer als 63 Bits sind (9223372036854775807),
zu verwenden, ausser für Bit-Felder!
MySQL 4.0 bietet eine bessere BIGINT-Handhabung als MySQL 3.23.
Bei allen Zeichenketten-Spalten ausser bei BLOB- und
TEXT-Spalten werden Leerzeichen am Ende automatisch entfernt, wenn
sie abgerufen werden. Bei CHAR-Typen ist das okay und kann gemäß
ANSI-SQL92 als ein Feature betrachtet werden. Der Bug besteht darin, dass
in MySQL auch VARCHAR-Spalten auf dieselbe Art behandelt werden.
Pro Tabelle können höchstens 255 ENUM- und SET-Spalten
verwendet werden.
safe_mysqld leitet alle Nachrichten von mysqld in die
mysqld-Logdatei um. Ein Problem ergibt sich, wenn Sie
mysqladmin refresh benutzen, um die Logdatei zu schließen und
wieder zu öffnen. In diesem Fall werden stdout und stderr
immer noch in die alte Logdatei geleitet.
Wenn Sie --log umfangreich benutzen, sollten Sie safe_mysqld
editieren, um in 'hostname'.err anstelle von 'hostname'.log
zu loggen, damit Sie den Speicherplatz für das alte Log leicht neu belegen
können, indem Sie das alte Log löschen und mysqladmin refresh
ausführen.
Im UPDATE-Statement, werden Spalten von links nach rechts
aktualisiert (Update). Wenn Sie sich auf eine aktualisierte Spalte
beziehen, erhalten Sie den aktualisierten Werte anstelle des ursprünglichen
Werts. Beispiel:
mysql> UPDATE tabelle SET KEY=KEY+1,KEY=KEY+1;
Dieses Statement aktualisiert KEY mit 2 anstelle von
1.
Sie können temporäre Tabellen nicht öfter als einmal innerhalb derselbe Anfrage benutzen. Das Folgende zum Beispiel funktioniert nicht:
select * from temporaere_tabelle, temporaere_tabelle as t2;
RENAME funktioniert nicht bei TEMPORARY-Tabellen.
Unter Umständen behandelt der Optimierer (Optimizer) DISTINCT
unterschiedlich, je nachdem, ob Sie 'versteckte' Spalten in einem Join
benutzen oder nicht. In einem Join werden versteckte Spalten als Teil des
Ergebnisses gezählt (selbst wenn sie nicht angezeigt werden), während
versteckte Spalten in normalen Anfragen nicht an einem DISTINCT-Vergleich
teilnehmen. Zukünftig werden wir dieses Verhalten wahrscheinlich ändern, so
dass versteckte Spalten nie verglichen werden, wenn DISTINCT ausgeführt
wird.
Hierfür ein Beispiel:
SELECT DISTINCT mp3id FROM band_downloads WHERE userid = 9 ORDER BY id DESC;
und
SELECT DISTINCT band_downloads.mp3id, FROM band_downloads,band_mp3 WHERE band_downloads.userid = 9 AND band_mp3.id = band_downloads.mp3id ORDER BY band_downloads.id DESC;
Im zweiten Fall bekommen Sie in MySQL 3.23.x möglicherweise zwei identische Zeilen in der Ergebnismenge (weil die versteckten 'id'-Spalten unterschiedlich sein können).
Beachten Sie, dass dies nur für Anfragen zutrifft, bei denen die ORDER BY-Spalten nicht im Ergebnis enthalten sind. ANSI-SQL erlaubt dies nicht
Weil MySQL es zuläßt, mit Tabellentypen zu arbeiten, die keine
Transaktionen unterstützen (und folglich Daten nicht per rollback in
den vorherigen Zustand bringen können), verhalten sich einige Dinge in
MySQL etwas anderes als in anderen SQL-Servern. Das kann manchmal etwas
ungünstig sein, weil Spaltenwerte in der Applikation überprüft werden
müssen. Auf der anderen Seite erhalten Sie dadurch eine nette
Geschwindigkeitssteigerung, weil es MySQL gestattet, einige Optimierungen
vorzunehmen, die ansonsten sehr schwer durchzuführen sein würden.
Wenn Sie eine Spalte auf einen nicht zulässigen Wert setzen, speichert
MySQL, statt ein Rollback durchzuführen, den besten möglichen Wert
in der Spalte:
Wenn Sie versuchen, in einer numerischen Spalte einen Wert ausserhalb des Wertebereichs zu speichern, speichert MySQL statt dessen den kleinsten oder größten möglichen Wert.
Wenn Sie versuchen, eine Zeichenkette, die nicht mit einer Zahl beginnt, in einer numerischen Spalte zu speichern, speichert MySQL 0.
Wenn Sie versuchen, NULL in einer Spalte zu speichern, die keine
NULL-Werte zuläßt, speichert MySQL 0 oder '' (leere
Zeichenkette). (Man kann dieses Verhalten jedoch mit der
-DDONT_USE_DEFAULT_FIELDS-Kompilierungs-Option ändern.)
MySQL läßt zu, dass einige falsche Datumswerte in DATE- und
DATETIME-Spalten gespeichert werden (wie 2000-02-31 oder
2000-02-00). Wenn das Datum völlig falsch ist, speichert MySQL den
speziellen Datumswert 0000-00-00 in der Spalte.
Wenn Sie enum auf einen nicht unterstützten Wert setzen, wird es auf
den Fehlerwert 'leere Zeichenkette' oder (bei numerischen Werten) auf 0
gesetzt.
Wenn Sie PROCEDURE auf eine Anfrage ausführen, die eine leere
Ergebnismenge liefert, kann es in einigen Fällen vorkommen, dass
PROCEDURE die Spalten nicht umwandelt.
Wenn Sie eine Tabelle vom Typ MERGE anlegen, wird nicht überprüft,
ob die zugrunde liegenden Tabellen von einem kompatiblen Typ sind.
MySQL kann bislang nicht mit NaN-, -Inf- und
Inf-Werten in Doubles umgehen. Wenn Sie diese benutzen, gibt es
Probleme, wenn Daten importiert oder exportiert werden. Als Zwischenlösung
sollten Sie NaN in NULL umwandeln (falls möglich) und
-Inf und Inf in den kleinsten bzw. größten möglichen Wert.
Negative Zahlen in der LIMIT-Klausel werden als große positive
Zahlen behandelt.
Wenn Sie ALTER TABLE benutzen, um einen UNIQUE-Index zu einer
Tabelle hinzuzufügen, die in einer MERGE-Tabelle benutzt wird, und
dann ALTER TABLE benutzen, um der MERGE-Tabelle einen
normalen Index hinzuzufügen, weicht die Reihenfolge der Schlüssel für die
Tabellen ab. Das liegt daran, dass ALTER TABLE
UNIQUE-Schlüssel vor normalen Schlüsseln einfügt, um doppelte
Schlüssel so früh wie möglich erkennen zu können.
Folgende bekannte Bugs gibt es in früheren Versionen von MySQL:
Man kann einen hängenden Thread erhalten, wenn man DROP TABLE auf
eine Tabelle ausführt, die zu vielen Tabellen gehört, die mit LOCK TABLES gesperrt sind.
In folgenden Fällen können Sie einen Core Dump erhalten:
Die Routine für verzögertes Einfügen (Delayed Insert Handler) hat noch nie ausgeführte Einfügeoperationen (Pending Inserts) auf eine Tabelle.
LOCK tabelle mit WRITE
FLUSH TABLES
Vor MySQL-Version 3.23.2 kann ein UPDATE fehlschlagen, dass einen
Schlüssel mit einer WHERE-Klausel auf denselben Schlüssel
aktualisiert, weil der Schlüssel benutzt wurde, um nach Datensätzen zu
suchen, und dieselbe Zeile mehrfach gefunden wurde:
UPDATE tabelle SET KEY=KEY+1 WHERE KEY > 100;
Ein Workaround besteht in der Benutzung von:
mysql> UPDATE tabelle SET KEY=KEY+1 WHERE KEY+0 > 100;
Das funktioniert, weil MySQL auf Ausdrücke (Expressions) in der
WHERE-Klausel keine Indizes benutzt.
Vor MySQL-Version 3.23 wurden alle numerischen Typen als Festkomma-Felder behandelt. Das bedeutet, dass Sie festlegen müssen, wie viele Dezimalstellen ein Fließkomma-Feld haben soll. Alle Werte wurden mit der korrekten Anzahl von Dezimalstellen zurückgegeben.
Was Plattform-spezifische Bugs angeht, sehen Sie bitte im Abschnitt über Kompilieren und Portieren nach.
© 1995-2005 MySQL AB. All rights reserved.
