Inhaltsverzeichnis
Die Übersetzung einer so umfangreichen technischen Dokumentation wie des MySQL-Referenzhandbuchs ist schon eine besondere Herausforderung. Zumindest für jemanden, der seine Zielsprache ernst nimmt:
In diesem Handbuch wird nicht geupdated, sondern aktualisiert.
Eine MySQL-Distribution wird nicht gedownloaded, sondern herunter geladen.
Und Transaktionen werden nicht gerollbackt, sondern zurückgerollt.
Womit wir auch schon bei der besonderen Herausforderung wären: Jeder, der sich mit Transaktionen auskennt, weiß, dass beim Fehlschlagen einer solchen ein Rollback-Befehl ausgeführt wird. Dieses Hauptwort ins Deutsche zu übersetzen, würde zum Verständnis wenig beitragen - im Gegenteil.
Damit bleiben alle technischen Fachbegriffe, die sich so und nicht anders etabliert haben, englisch:
Ein SQL-Statement wird nicht als "Erklärung in der Strukturierten AbfrageSprache (SAS)" übersetzt.
Abkürzungen wie TCP/IP werden nicht zu ÜSP/ZP (ÜbertragungsSteuerungsProtokoll/ZwischennetzProtokoll).
Ein Client bleibt ein Client, und ein Server ein Server.
Die Fallstricke einer Übersetzung stecken allerdings in den Details:
Jeder SQL-Kenner weiß, was eine "query" ist. In diesem Handbuch ist das eine Anfrage.
Gibt es Probleme bei der Übermittlung einer Anfrage, kann es sein, dass eine Zeitüberschreitung eintritt. Der Profi hätte wahrscheinlich nach "Timeout" gesucht.
Manche Dinge sind einfacher: Ein "string" ist eine Zeichenkette (obwohl für Profis vielleicht ungewohnt), ein "hex value" ein hexadezimaler Wert.
Richtig spannend wird die Übersetzung bei Wörtern, die in der deutschen Fachsprache zumeist englisch verwendet werden, obwohl es passende deutsche Entsprechungen gibt:
Im Hauptspeicher ("RAM") zwischengespeicherte Daten werden auf die Festplatte zurückgeschrieben. Im Englischen heißt das "flushed to disk", und im Deutschen werden die Daten häufig "geflushed".
Daten werden zwischengespeichert ("gecached").
Speicher wird zugewiesen. Man kann auch "alloziert" sagen, was dem englischen "allocated" näher kommt.
Alle diese Entsprechungen, bei denen die deutsche Sprache eher in Vergessenheit geraten ist, wurden zweisprachig aufgenommen. Beispiele:
Alle Daten werden zwischen Anfragen auf die Festplatte zurück geschrieben (flush).
Aktualisieren Sie (Update), wenn alles in Ordnung ist.
Auf eine höhere Version von MySQL aktualisieren (Upgrade) ...
Gelegentlich wird auch in diesem Handbuch die "Performance getuned", neue "Features" eines MySQL-"Release" werden beschrieben usw. Anregungen für eine weiter gehende Eindeutschung nimmt der Übersetzer gern entgegen. Insbesondere gilt das auch für Hinweise zur Verkürzung deutscher Ausdrücke. Beispielsweise heißt "case sensitive" (14 Buchstaben) im Handbuch "abhängig von der verwendeten Groß-/Kleinschreibung" (44 Buchstaben).
Letzter Punkt: Die Übersetzung erfolgte in äußerst enger Anlehnung an das englischsprachige Original. Nichts wurde hinzugefügt (ausser diesem Vorwort), geändert oder weggelassen (Ausnahme: die Geschichte der Änderungen (ChangeLog) vor Version 3.23). Es liegt in der Natur der Dinge, dass weder Original noch Übersetzung frei von Fehlern sind (obwohl wir das anstreben). Berichten Sie bitte Übersetzungsfehler, stilistische "Bugs", die das Verständnis beeinträchtigen und sonstige Anmerkungen zur Übersetzung direkt an:
Stefan Hinz, <stefan@mysql.com>
Berlin, im Februar 2002
Stefan Hinz
Das ist ein Referenzhandbuch. Es enthält keine allgemeinen Anleitungen zu SQL oder relationalen Datenbankkonzepten.
Da die MySQL Datenbank Software eine laufende Weiterentwicklung
erfährt, wird das Handbuch regelmäßig aktualisiert. Die jeweils
aktuellste Version dieses Handbuchs befindet sich unter
http://www.mysql.com/documentation/.
Dieses Handbuch ist gegenwärtig verfügbar in Texinfo, als
Klartext (plain text), Info, HTML, PostScript und PDF. Das
Primärdokument ist die Texinfo-Datei. Die HTML-Version wird
automatisch produziert, indem eine modifizierte Version von
texi2html benutzt wird. Die Klartext- und Info-
Versionen werden mit makeinfo hergestellt. Die
PostScript-Version wird mit texi2dvi und
dvips produziert. Die PDF-Version wird mit
pdftex hergestellt.
Wenn Sie Schwierigkeiten haben, Informationen zu finden, beachten Sie bitte auch die durchsuchbare PHP Version des Handbuchs unter http://www.mysql.com/doc/.
Wenn Sie Vorschläge für Hinzufügungen oder Korrekturen dieses
Handbuchs haben, schicken Sie sie bitte an das Handbuch-Team:
<docs@mysql.com>.
Dieses Handbuch wurde geschrieben und wird gewartet von David Axmark, Michael (Monty) Widenius, Jeremy Cole, und Paul DuBois. Andere Kontributoren sind unter Anhang B, Danksagungen aufgelistet. Die deutsche Übersetzung stammt von Stefan Hinz. Für die Aktualität ist Jan Lehnardt zuständig.
Das Copyright (2002) für dieses liegt bei der schwedischen Firma
MySQL AB. See Abschnitt 2.4.2, „Copyrights und Lizenzen, die von MySQL verwendet werden.“.
Dieses Handbuch benutzt bestimmte typographische Konventionen:
constant
Schriftart gleicher Breite (nicht-proportionale Schrift)
wird für Befehle und Optionen benutzt, für SQL-Statements,
Datenbank-, Tabellen- und Spaltennamen, für C- und
PERL-Code und für Umgebungsvariablen. Beispiel: ``Um
festzustellen, wie mysqladmin
funktioniert, rufen Sie den Befehl mit der
--help Option auf.''
filename
Schriftart gleicher Breite, die von Anführungszeichen
umgeben ist, wird für Datei- und Pfadnamen benutzt.
Beispiel: ``Die Distribution wird im Verzeichnis
/usr/local/ installiert.''
‘c’
Schriftart gleicher Breite, die von Anführungszeichen
umgeben ist, wird auch benutzt um Zeichenfolgen anzuzeigen.
Beispiel: ``Um ein Platzhalterzeichen einzugeben, benutzen
Sie das ‘%’ Zeichen.''
italic
Kursivschrift wird für Hervorhebungen verwendet, wie in diesem Beispiel.
boldface
Fettschrift wird für Namen von Zugriffsrechten verwendet (zum Beispiel: ``Gewähren Sie das process Zugriffsrecht nicht leichtfertig'') und gelegentlich, um besonders starke Hervorhebungen zu kennzeichnen.
Wenn Befehle gezeigt werden, die durch ein bestimmtes Programm
ausgeführt werden sollen, wird dieses Programm durch einen
Prompt (Eingabeaufforderung) vor dem Befehl angezeigt. Der
shell> Prompt zum Beispiel zeigt an, dass
Sie den Befehl von Ihrer Login-Shell aus ausführen sollen.
mysql> zeigt an, dass Sie den Befehl vom
mysql Client-Programm aus ausführen sollen:
shell>geben sie hier ein shell-kommando einmysql>geben sie hier ein mysql-kommando ein
Shell-Befehle werden mit der Bourne-Shell-Syntax dargestellt.
Wenn Sie eine csh-Shell benutzen, müssen die
Befehle evtl. etwas anders eingegeben werden. Das folgende
Beispiel zeigt, wie mit der Bourne-Shell eine Umgebungsvariable
gesetzt wird und anschließend ein Befehl abgesetzt wird:
shell> VARNAME=wert irgendein_befehl
Um csh auszuführen, würden Sie folgende
Sequenz ausführen:
shell>setenv VARNAME wertshell>irgendein_befehl
Oft müssen Datenbank-, Tabellen- und Spaltennamen in konkreten
Befehlen ersetzt werden. Um anzuzeigen, dass eine solche
Ersetzung notwendig ist, benutzt dieses Handbuch
db_name, tbl_name und
col_name. Sie könnten zum Beispiel folgendes
Statement sehen:
mysql> SELECT spalten_name FROM datenbank_name.tabellen_name;
Wenn Sie ein ähnliches Statement eingeben wollen, müssen Sie Ihre eigenen Datenbank-, Tabellen- und Spaltennamen eingeben, zum Beispiel wie folgt:
mysql> SELECT autor_name FROM bibliothek.autorenliste;
SQL-Statements können in Groß- und Kleinschreibung geschrieben
werden. Wenn dieses Handbuch SQL-Statements darstellt, wird
Großschreibung verwendet, um spezielle Schlüsselworte in
diesem Kontext hervorzuheben. Kleinschreibung wird für den Rest
des Statements verwendet. Folgendes könnten Sie im Kontext des
SELECT Statements sehen:
mysql> SELECT count(*) FROM tabellen_name;
Im Kontext der COUNT() Funktion hingegen
könnte dasselbe Statement wie folgt geschrieben werden:
mysql> select COUNT(*) from tabellen_name;
Wenn keine besondere Hervorhebung beabsichtigt wird, werden alle Schlüsselworte in Großschreibung dargestellt.
In Syntax-Beschreibungen werden eckige Klammern
(‘[’ und
‘]’) benutzt, um wahlfrei
(optionale) Wörter oder Klauseln anzuzeigen:
DROP TABLE [IF EXISTS] tabellen_name
Wenn ein Syntaxelement aus einer Anzahl von Alternativen
besteht, werden die Alternativen durch gerade Striche
(‘|’) voneinander getrennt. Wenn
genau ein Element aus einer Anzahl von Möglichkeiten
ausgewählt werden (kann),
werden die Alternativen mit eckigen Klammern aufgelistet
(‘[’ und
‘]’):
TRIM([[BOTH | LEADING | TRAILING] [remstr] FROM] str)
Wenn genau ein Element aus einer Anzahl von Möglichkeiten
ausgewählt werden muss, werden
die Alternativen innerhalb geschweifter Klammern aufgelistet
(‘{’ und
‘}’):
{DESCRIBE | DESC} tbl_name {col_name | wild}
MySQL, die populärste Open Source SQL-Datenbank, wird von MySQL AB zur Verfügung gestellt. MySQL AB ist ein kommerzielles Unternehmen, dessen Geschäft darin besteht, Serviceleistungen rund um die MySQL-Datenbank zur Verfügung zu stellen. See Abschnitt 2.3, „Was ist MySQL AB?“.
MySQL ist ein Datenbank-Managementsystem.
Eine Datenbank ist eine strukturierte Sammlung von Daten. Das kann alles sein - von einer einfachen Einkaufsliste über eine Bildergalerie bis zu riesigen Informationsmengen in einem Unternehmensnetzwerk. Um Daten zu einer Computer-Datenbank hinzuzufügen, auf sie zuzugreifen und sie zu verarbeiten, benötigen Sie ein Datenbank-Managementsystem wie MySQL. Weil Computer sehr gut darin sind, große Datenmengen zu handhaben, spielt Datenbank-Management eine zentrale Rolle im Computer-Bereich, sowohl bei Anwendungen, die allein laufen (Stand-Alone-Utilities) als auch als Teil anderer Anwendungen.
MySQL ist ein relationales Datenbank-Managementsystem.
Eine relationale Datenbank speichert Daten in separaten Tabellen, anstatt sie alle in einem einzigen großen Speicherraum unterzubringen. Hierdurch werden hohe Geschwindigkeit und Flexibilität erreicht. Die Tabellen werden durch definierte Beziehungen verbunden (Relationen), was es möglich macht, Daten aus verschiedenen Tabellen auf Nachfrage zu kombinieren. Der SQL-Teil von MySQL steht für "Structured Query Language" (strukturierte Abfragesprache) - die verbreitetste standardisierte Sprache für Datenbankzugriffe.
MySQL ist Open-Source-Software.
Open Source bedeutet, dass es für jeden möglich ist, solche Software zu benutzen und zu verändern. Jeder kann MySQL aus dem Internet herunter laden und benutzen, ohne irgend etwas zu bezahlen. Jeder, der daran interessiert ist, kann den Quelltext studieren und den eigenen Bedürfnissen entsprechend verändern. MySQL benutzt die GPL (GNU General Public License) http://www.gnu.org, um festzulegen, was Sie mit der Software tun dürfen und was Sie nicht tun dürfen, abhängig von unterschiedlichen Situationen. Wenn Ihnen die GPL Probleme bereitet oder wenn Sie MySQL in eine kommerzielle Anwendung einbetten müssen, können Sie eine kommerziell lizensierte Version von uns erwerben.
Warum sollten Sie MySQL benutzen?
MySQL ist sehr schnell, zuverlässig und leicht zu benutzen. Wenn Sie nach diesen Eigenschaften suchen, sollten Sie MySQL ausprobieren. MySQL besitzt eine ganze Reihe praktischer Features, die in enger Kooperation mit unseren Benutzern entwickelt wurden. Einen Performance-Vergleich zwischen MySQL und einigen anderen Datenbank-Managementsystemen finden Sie auf unserer Benchmark-Seite. See Abschnitt 6.1.4, „Die MySQL-Benchmark-Suite“.
MySQL wurde ursprünglich entwickelt, um sehr große Datenbanken handhaben zu können, und zwar sehr viel schneller als existierende Lösungen. Es wurde mehrere Jahre in höchst anspruchsvollen Produktionsumgebungen eingesetzt. Heutzutage bietet MySQL eine umfangreiche Reihe sehr nützlicher Funktionen. Connectivity, Geschwindigkeit und Sicherheit machen MySQL äußerst geeignet, um auf Datenbanken über das Internet zuzugreifen.
Die technischen Features von MySQL
Weiter führende technische Informationen finden Sie unter Kapitel 7, MySQL-Sprachreferenz. MySQL ist ein Client-Server-System, das aus einem multi-thread SQL-Server besteht, der unterschiedliche Backends, verschiedene Client-Programme und -Bibliotheken, Verwaltungswerkzeuge und etliche Programmschnittstellen unterstützt.
Wir stellen MySQL auch als multi-thread Bibliothek zur Verfügung, die Sie mit Ihren Anwendungen verknüpfen können, um ein kleineres, schnelleres und leichter zu bedienendes Produkt zu erhalten.
MySQL stellt beigesteuerte (contributed) Software in großer Menge
zur Verfügung.
Es ist sehr wahrscheinlich, dass Ihre Lieblingsanwendung oder -sprache bereits MySQL unterstützt.
Offiziell wird MySQL 'Mai Ess Ku Ell' ausgesprochen (nicht 'Mai Siekwel'). Wir vermeiden allerdings, Leute zu korrigieren, die Mai-Siekwel sagen.
Wir fingen ursprünglich mit der Intention an, den
mSQL-Code zu benutzen, um unsere eigenen
Tabellen anzusprechen, wobei wir unsere eigenen schnellen
Low-Level-Routinen (ISAM) benutzten. Nach einigem Testen gelangten
wir allerdings zur Überzeugung, dass mSQL
weder schnell noch flexibel genug wäre, um unsere Anforderungen
abzudecken. Dies resultierte in einer neuen SQL-Schnittstelle zu
unserer Datenbank, allerdings mit fast derselben
API-Schnittstelle, wie sie mSQL benutzt. Diese
API wurde gewählt, weil sie es erlaubte, Code von Drittanbietern
einfach zu portieren. Die Entstehung des Namens MySQL ist nicht
völlig geklärt. Unser Basis-Verzeichnis und eine große Anzahl
unserer Bibliotheken und Werkzeuge hatten immer schon das Präfix
``my'' während mehr als 10 Jahren. Wie auch immer, auch Montys
Tochter (einige Jahre jünger) heißt My. Welcher der beiden
Umstände MySQL den Namen gab, ist immer noch ein Rätsel, sogar
für uns.
Die folgende Liste beschreibt einige wichtige Charakteristika von MySQL:
Voll multi-thread unter Benutzung von Kernel-Threads. Das bedeutet, dass Sie sehr einfach mehrere Prozessoren benutzen können, falls verfügbar.
C-, C++-, Eiffel-, Java-, Perl-, PHP-, Python- und Tcl-APIs. See Kapitel 9, MySQL-APIs.
Läuft auf vielen verschiedenen Plattformen. See Abschnitt 3.2.2, „Betriebssysteme, die von MySQL unterstützt werden“.
Viele Spaltentypen: vorzeichenbehaftete / vorzeichenlose
Ganzzahlen (Integer), die 1, 2, 3, 4 und 8 Byte lang sind,
FLOAT, DOUBLE,
CHAR, VARCHAR,
TEXT, BLOB,
DATE, TIME,
DATETIME, TIMESTAMP,
YEAR, SET, und
ENUM Typen. See
Abschnitt 7.2, „Spaltentypen“.
Sehr schnelle Joins durch Benutzung eines optimierten Multi-Joins in einem Durchgang (one-sweep multi-join).
Volle Operator- und Funktionsunterstützung in
SELECT- und
WHERE-Teilen von Anfragen. Beispiel:
mysql> SELECT CONCAT(vorname, " ", nachname) FROM tabellen_name
WHERE einkommen/dependents > 10000 AND age > 30;
SQL-Funktionen sind durch eine hoch optimierte Klassenbibliothek implementiert und sollten so schnell sein, wie es geht! Üblicherweise gibt es überhaupt keine Speicherzuordnung (memory allocation) nach der Initialisierung von Anfragen.
Volle Unterstützung für SQL-GROUP BY
und ORDER BY- Klauseln. Unterstützung
für Gruppierungsfunktionen (COUNT(),
COUNT(DISTINCT ...),
AVG(), STD(),
SUM(), MAX() und
MIN()).
Unterstützung für LEFT OUTER JOIN und
RIGHT OUTER JOIN mit ANSI-SQL und
ODBC-Syntax.
Sie können Tabellen aus unterschiedlichen Datenbanken in ein und derselben SQL-Anfrage benutzen (ab Version 3.22).
Ein System von Zugriffsberechtigungen und Passwörtern, das sehr flexibel und sicher ist, und das Host-basierende Verifizierung erlaubt. Passwörter sind sicher, weil jeder Passwort-Verkehr verschlüsselt wird, wenn Sie sich mit einem Server verbinden.
ODBC (Open-DataBase-Connectivity) Unterstützung für Win32 (mit Quelltext). Alle ODBC 2.5 Funktionen und viele weitere. Sie können zum Beispiel MS Access benutzen, um sich mit Ihrem MySQL-Server zu verbinden. See Abschnitt 9.3, „MySQL-ODBC-Unterstützung“.
Sehr schnelle B-tree disk Tabellen mit Index-Kompression.
Bis zu 32 Indexe pro Tabelle erlaubt. Jeder Index kann aus 1
bis 16 Spalten oder Teilen von Spalten bestehen. Die
maximale Indexlänge beträgt 500 Bytes (das ändert sich
evtl., wenn MySQL kompiliert wird). Ein Index kann das
Präfix eines CHAR- oder
VARCHAR-Felds benutzen.
Datensätze fester und variabler Länge.
Im Arbeitsspeicher gehaltene Hash-Tabellen, die als temporäre Tabellen benutzt werden.
Kann große Datenbanken handhaben. Wir selbst benutzen MySQL bei einigen Datenbanken, die 50 Mio. Datensätze haben und wir kennen Benutzer, die MySQL mit 60.000 Tabellen und etwa 5 Milliarden Zeilen benutzen.
Alle Spalten können Vorgabewerte (Defaults) haben. Sie
können INSERT benutzen, um eine
Untermenge der Tabellenspalten mit Werten zu bestücken.
Diejenigen Spalten, die nicht explizit angesprochen werden,
werden auf ihre Vorgabewerte gesetzt.
Benutzt GNU Automake, Autoconf und Libtool aus Portabilitätsgründen.
Geschrieben in C und C++. Getestet mit großen Anzahl verschiedener Compiler.
Ein sehr schnelles Thread-basierendes Speicherzuordnungs-System (memory allocation system).
Keine Speicherlecks (memory leaks). MySQL wurde mit Purify getestet, einem kommerziellen Werkzeug zur Entdeckung von Speicherlecks.
Beinhaltet myisamchk, ein sehr schnelles
Dienstprogramm zur Überprüfung, Optimierung und Reparatur
von Tabellen. Die gesamte Funktionalität von
myisamchk steht auch über die
SQL-Schnittstelle zur Verfügung. See
Kapitel 5, MySQL-Datenbankadministration.
Volle Unterstützung für mehrere unterschiedliche Zeichensätze, incl. ISO- 8859-1 (Latin1), big5, ujis und weitere. So sind zum Beispiel die skandinavischen Zeichen `a*', `ä' und `ö' in Tabellen- und Spaltennamen erlaubt.
Alle Daten werden mit dem ausgewählten Zeichensatz gespeichert. Alle Vergleiche für normale Zeichenkettenvergleiche sind unabhängig von Groß- und Kleinschreibung.
Die Sortierung ist abhängig vom gewählten Zeichensatz (schwedisch als Vorgabe). Das kann beim Start des MySQL-Servers geändert werden. Um beispielsweise eine sehr fortgeschrittene Sortierung zu sehen, sehen Sie sich den tschechischen Sortier-Code an. MySQL unterstützt viele unterschiedliche Zeichensätze, die bei der Kompilierung und während der Laufzeit festgelegt werden können. Der neue Zeichensatz 'latin_de' sorgt für eine korrekte deutsche Sortierreihenfolge.
Aliase auf Tabellen und Spalten sind erlaubt, wie im SQL92-Standard festgelegt.
DELETE, INSERT,
REPLACE und UPDATE
geben die Anzahl der Zeilen zurück, die geändert wurden
(bzw. betroffen sind). Es ist statt dessen auch möglich,
die Anzahl der übereinstimmenden Zeilen zurückzugeben,
indem beim Verbindungsstart zum Server ein entsprechendes
Flag gesetzt wird.
Funktionsnamen kollidieren nicht mit Tabellen- oder
Spaltennamen. ABS zum Beispiel ist ein
gültiger Spaltenname. Die einzige Einschränkung besteht
drin, dass in einem Funktionsaufruf keine Leerzeichen
zwischen Funktionsname und der öffnenden runden Klammer,
die diesem folgt ‘(’, erlaubt
ist. See Abschnitt 7.1.6, „Ist MySQL pingelig hinsichtlich reservierter Wörter?“.
Alle MySQL-Programme können mit der --help
oder -? Option aufgerufen werden, um
Online-Hilfe zu erhalten.
Der Server kann Clients Fehlermeldungen in verschiedenen Sprachen zur Verfügung stellen. See Abschnitt 5.6.2, „Nicht englische Fehlermeldungen“.
Clients können sich mit dem MySQL-Server über TCP/IP Sockets, Unix Sockets (Unix) oder Named Pipes (NT) verbinden.
Der MySQL-spezifische SHOW-Befehl kann
benutzt werden, um Informationen über Datenbanken, Tabellen
und Indexe zu erhalten. Der EXPLAIN-Code
kann benutzt werden um festzustellen, wie der Optimierer
eine Anfrage auflöst.
Dieser Abschnitt beschäftigt sich mit den Fragen ``Wie stabil ist MySQL?'' und ``Kann ich mich auf MySQL bei diesem Projekt verlassen?'' Wir werden versuchen, einige Dinge klar zu stellen und einige der wichtigeren Fragen zu beantworten, die offensichtlich viele Leute beschäftigen. Dieser Abschnitt wurde aus Informationen zusammen gestellt, die aus der Mailing-Liste gesammelt wurden (die sehr aktiv beim Berichten von Bugs ist).
Bei TcX funktioniert MySQL ohne jegliche Probleme in unseren Projekten seit Mitte 1996. Als MySQL einer breiteren Öffentlichkeit zugänglich gemacht wurde, fiel uns auf, dass es einige Teile von ``ungetestetem Code'' gab, die schnell von neuen Benutzern gefunden wurden, die Anfragen machten, die von unseren eigenen abwichen. Seitdem hat jedes neue Release weniger Portabilitätsprobleme als das vorhergehende (obwohl jedes viele neue Features hat).
Jedes Release von MySQL war benutzbar. Probleme gab es nur, wenn Benutzer anfingen, Code aus den ``Grauzonen'' zu benutzen. Natürlich wissen Benutzer von ausserhalb nicht, was diese Grauzonen sind, daher versucht dieser Abschnitt, die momentan bekannten aufzuzeigen. Die Beschreibungen hier beziehen sich auf Version 3.23 von MySQL. Alle bekannten und berichteten Bugs werden in der letzten Version behoben, mit Ausnahme der Bugs, die im Bugs-Abschnitt aufgelistet sind, was Dinge sind, die auf das Design zurückzuführen sind. See Abschnitt 2.7.5, „Bekannte Fehler und Design-Unzulänglichkeiten in MySQL“.
MySQL ist in mehrfachen Ebenen (Layers) und verschiedenen unabhängigen Modulen geschrieben. Diese Module sind im Folgenden aufgeführt, wobei angezeigt wird, wie gut getestet jedes von ihnen ist:
Der ISAM Tabellen-Handler --- stabil
Dieser verwaltet Speicherung und Abfrage aller Daten in MySQL Version 3.22 und früher. In allen Releases von MySQL gab es nicht einen einzigen (berichteten) Bug in diesem Code. Die einzige Möglichkeit, eine zerstörte (korrumpierte) Tabelle zu erhalten, besteht darin, den Server mitten während eines Updates zu killen. Selbst dadurch ist es unwahrscheinlich, dass Daten unwiederbringlich zerstört werden, denn alle Daten werden zwischen Anfragen auf die Festplatte zurück geschrieben (flush). Es hat nicht einen einzigen Bug-Bericht gegeben, in dem von verlorenen Daten aufgrund von MySQL-Bugs berichtet wurde.
Der MyISAM Tabellen-Handler --- stabil
Dieser wurde in MySQL Version 3.23 hinzu gefügt. Er basiert zum großen Teil auf dem ISAM Tabellen-Code, hat aber eine Menge neuer und sehr nützlicher Features.
Der Parser und lexikalische Analysator --- stabil
Es hat seit sehr langer Zeit keinen einzigen berichteten Bug in diesem System gegeben.
Der C Client-Code --- stabil
Keine bekannten Probleme. Im frühen 3.20 Release gab es einige Einschränkungen hinsichtlich der Größe des Sende- / Empfangs-Puffers (buffer size). Ab Version 3.21 ist die Puffergröße jetzt dynamisch, bis zu einem Vorgabewert von 16 M.
Standard-Client-Programme --- stabil
Dies beinhaltet mysql,
mysqladmin, mysqlshow,
mysqldump und
mysqlimport.
Basis-SQL --- stabil
Die grundlegenden SQL-Funktionen, Zeichenketten-Klassen und dynamisches Speicher-Handling. Nicht ein einziger berichteter Bug in diesem System.
Anfragen-Optimierer (Query optimizer) --- stabil
Bereichs-Optimierer (Range optimizer) --- stabil
Join-Optimierer (Join optimizer) --- stabil
Sperren (Locking) --- Gamma
Dies ist sehr system-abhängig. Auf einigen Systemen gibt es
große Probleme, wenn Standard-Betriebssystem-Sperren
verwendet wird (fcntl()). In solchen
Fällen sollten Sie den MySQL-Daemon mit dem Flag
--skip-locking laufen lassen. Bekannt ist,
dass solche Probleme auf manchen Linux-Systemen vorkommen
sowie auf SunOS, wenn NFS- gemountete Dateisysteme verwendet
werden.
Linux-Threads --- stabil
Das hauptsächliche Problem fand sich im
fcntl()-Aufruf, der durch Benutzung der
--skip-locking-Option bei
mysqld behoben werden kann. Einige Leute
haben Lockup-Probleme mit Version 0.5 berichtet.
Linux-Threads müssen rekompiliert werden, wenn Sie mehr als
1000 gleichzeitige Verbindungen benutzen wollen. Obwohl es
möglich ist, so viele Verbindungen mit den vorgabemäßigen
Linux-Threads laufen zu lassen (obwohl man nie über 1021
kommen wird), macht das vorgabemäßige Stack-Spacing von 2
MB die Applikation unstabil, und wir konnten einen Coredump
reproduzieren, nachdem 1021 Verbindungen im Leerlauf (idle
connections) hergestellt wurden. See
Abschnitt 3.6.1, „Linux (alle Linux-Versionen)“.
Solaris 2.5+ pthreads --- stabil
Wir benutzen dies für unsere gesamte Produktionsarbeit.
MIT-pthreads (andere Systeme) --- stabil
Seit Version 3.20.15 gab es keine berichteten Bugs mehr, und
keine bekannten Bugs seit Version 3.20.16. Auf einigen
Systemen gibt es ein ``Misfeature'', das heißt einige
Operationen sind recht langsam (1/20 Sekunde Schlafzyklus
zwischen jeder Anfrage). Natürlich können MIT- Threads
alles ein bisschen verlangsamen, aber Index-basierende
SELECT-Statements werden üblicherweise
in einem Zeit-Frame ausgeführt, also sollte es kein mutex
locking/thread juggling geben.
Andere Thread-Implementierungen --- Beta - Gamma
Die Ports zu anderen Systemen sind noch sehr neu und können Bugs haben, möglicherweise auch in MySQL, aber in den meisten Fällen in der Thread- Implementierung selbst.
LOAD DATA ...,
INSERT ... SELECT --- stabil
Einige Leute dachten, hier Bugs gefunden zu haben, aber üblicherweise haben sich diese als Missverständnisse heraus gestellt. Bitte sehen Sie zuerst im Handbuch nach, bevor Sie Bugs berichten!
ALTER TABLE ---
stabil
Einige Änderungen in Version 3.22.12.
DBD --- stabil
Wird jetzt von Jochen Wiedmann gewartet
(<wiedmann@neckar-alb.de>). Danke!
mysqlaccess ---
stabil
Geschrieben und gewartet von Yves Carlier
(<Yves.Carlier@rug.ac.be>). Danke!
GRANT ---
stabil
große Änderungen in MySQL Version 3.22.12.
MyODBC (benutzt ODBC SDK 2.5) --- Gamma
Scheint mit einigen Programmen gut zu laufen.
Replikation -- Beta / Gamma
Wir arbeiten noch an der Replikation, also erwarten Sie nicht, dass diese schon felsenfest steht. Auf der anderen Seite benutzen MySQL- Benutzer diese bereits mit guten Resultaten.
BDB-Tabellen -- Beta
Der Berkeley-Datenbank-Code ist sehr stabil, aber wir verbessern immer noch die Schnittstelle zwischen MySQL und BDB-Tabellen, also wird es einige Zeit dauern, bevor dies so gut wie andere Tabellentypen getestet ist.
InnoDB-Tabellen -- stabil
Der transaktionale Tabellen-Handler
InnoDB wurde im MySQL
3.23-Baum stabil erklärt, ab Version 3.23.49.
InnoDB wird in großen hochbelasteten
Produktionssystemen eingesetzt.
Automatische Wiederherstellung von MyISAM-Tabellen - Beta
Dies betrifft nur den neuen Code, der beim Öffnen einer Tabelle nachsieht, ob diese korrekt geschlossen wurde und ein automatisches Überprüfen / Reparieren der Tabelle ausführt, falls das nicht der Fall war.
MERGE-Tabellen -- Beta / Gamma
Die Benutzung von Schlüsseln bei
MERGE-Tabellen ist noch nicht sehr
ausgetestet. Der restliche Teile des
MERGE-Codes ist recht gut getestet.
FULLTEXT -- Beta
Textsuche scheint zu funktionieren, wird aber noch nicht viel eingesetzt.
MySQL AB stellt E-Mail-Support für zahlende Kunden bereit, aber die MySQL-Mailingliste bietet üblicher Weise Antworten für die meisten Fragen. Bugs werden meist direkt mit einem Patch behoben; für schwerwiegende Bugs gibt es fast immer ein neues Release.
MySQL Version 3.22 hat eine Begrenzung auf 4G bei der
Tabellengröße. Mit dem neuen MyISAM in
MySQL Version 3.23 wurde die maximale Tabellengröße auf 8
Millionen Terabytes (2 ^ 63 bytes) hochgeschraubt.
Beachten Sie allerdings, dass Betriebssysteme ihre eigenen Dateigrößen- Beschränkungen haben. Hier sind einige Beispiele:
| Betriebssystem | Dateigrößen-Beschränkung |
| Linux-Intel 32 bit | 2G, 4G oder mehr, abhängig von der Linux-Version |
| Linux-Alpha | 8T (?) |
| Solaris 2.5.1 | 2G (möglich sind 4G mit Patch) |
| Solaris 2.6 | 4G |
| Solaris 2.7 Intel | 4G |
| Solaris 2.7 ULTRA-SPARC | 8T (?) |
Auf Linux 2.2 kann man größere Tabellen als 2G benutzen, wenn man den LFS-Patch für das ext2 Dateisystem benutzt. Auf Linux 2.4 existiert zusätzlich ein Patch für das ReiserFS, um Unterstützung für große Dateien zu erhalten.
Letztlich wird die Tabellengröße für MySQL normalerweise durch das Betriebssystem begrenzt.
Vorgabemäßig haben MySQL-Tabellen eine maximale Größe von
etwa 4G. Sie können die maximale Tabellengröße für eine
Tabelle mit dem SHOW TABLE STATUS-Befehl
überprüfen oder mit myisamchk -dv
tabellen_name. See Abschnitt 5.5.5, „SHOW-Syntax“.
Wenn Sie größere Tabellen als 4G benötigen (und Ihr
Betriebssystem dies unterstützt), sollten Sie die
AVG_ROW_LENGTH- und
MAX_ROWS-Parameter benutzen, wenn Sie Ihre
Tabelle anlegen. See Abschnitt 7.5.3, „CREATE TABLE-Syntax“. Sie können
diese auch später setzen, mit ALTER TABLE.
See Abschnitt 7.5.4, „ALTER TABLE-Syntax“.
Falls auf Ihre große Tabelle nur mit Lesezugriff zugegriffen
wird (read-only), können Sie auch myisampack
benutzen, um mehrere Tabellen zu vereinen (merge) und sie zu
einer zu komprimieren. myisampack komprimiert
eine Tabelle üblicherweise mindestens um 50%, also können Sie
effektiv viel größere Tabellen benutzen. See
Abschnitt 5.7.4, „myisampack, MySQL-Programm zum Erzeugen komprimierter Nur-Lese-Tabellen“.
Sie können die Dateibegrenzung des Betriebssystems für
MyISAM Daten-Dateien umgehen, indem Sie die
RAID-Option benutzen. See
Abschnitt 7.5.3, „CREATE TABLE-Syntax“.
Eine weitere Lösung kann die MERGE-Bibliothek darstellen, die Ihnen erlaubt, eine Sammlung identischer Tabellen zugleich zu benutzen. See Abschnitt 8.2, „MERGE-Tabellen“.
MySQL selbst hat keine Probleme mit der Jahr-2000-Konformität:
MySQL benutzt Unix-Zeitfunktionen und hat keine Probleme mit
Datumsangaben bis 2069. Alle
zweistelligen Jahresangaben werden als Angaben zwischen
1970 und 2069,
betrachtet, was bedeutet, dass, wenn Sie
01 in einer Spalte speichern, MySQL dies
als 2001 behandelt.
Alle MySQL Datumsfunktionen sind in einer Datei
sql/time.cc gespeichert und sehr
sorgfältig kodiert, um Jahr-2000-sicher zu sein.
In MySQL Version 3.22 und später kann der neue Spaltentyp
YEAR Jahre 0 und von
1901 bis 2155 in 1
Byte speichern und sie mit 2 oder 4 Ziffern anzeigen.
Probleme können Sie bekommen, wenn Sie MySQL mit Applikationen
benutzen, die MySQL auf eine Art benutzen, die nicht
Jahr-2000-sicher ist. Zum Beispiel speichern oder ändern viele
alte Applikationen Jahresangaben, indem sie zweistellige Werte
benutzen (was mehrdeutig ist), anstatt vierstellige Werte zu
nehmen. Dieses Problem kann durch Applikationen verschlimmert
werden, die Werte wie 00 oder
99 als Anzeiger ``fehlender'' Werte benutzen.
Leider sind diese Probleme möglicherweise schwer zu beheben, weil verschiedene Applikationen von unterschiedlichen Programmierern geschrieben sein können, von denen jeder einen anderen Satz von Konventionen und Funktionen benutzt haben kann, was die Handhabung von Datumsangaben betrifft.
Hier ist eine einfache Demonstration, die zeigt, dass MySQL keine Probleme mit Datumsangaben bis zum Jahr 2030 hat:
mysql>DROP TABLE IF EXISTS y2k;Query OK, 0 rows affected (0.01 sec) mysql>CREATE TABLE y2k (date date, date_time datetime, time_stamp timestamp);Query OK, 0 rows affected (0.00 sec) mysql>INSERT INTO y2k VALUES->("1998-12-31","1998-12-31 23:59:59",19981231235959),->("1999-01-01","1999-01-01 00:00:00",19990101000000),->("1999-09-09","1999-09-09 23:59:59",19990909235959),->("2000-01-01","2000-01-01 00:00:00",20000101000000),->("2000-02-28","2000-02-28 00:00:00",20000228000000),->("2000-02-29","2000-02-29 00:00:00",20000229000000),->("2000-03-01","2000-03-01 00:00:00",20000301000000),->("2000-12-31","2000-12-31 23:59:59",20001231235959),->("2001-01-01","2001-01-01 00:00:00",20010101000000),->("2004-12-31","2004-12-31 23:59:59",20041231235959),->("2005-01-01","2005-01-01 00:00:00",20050101000000),->("2030-01-01","2030-01-01 00:00:00",20300101000000),->("2050-01-01","2050-01-01 00:00:00",20500101000000);Query OK, 13 rows affected (0.01 sec) Records: 13 Duplicates: 0 Warnings: 0 mysql>SELECT * FROM y2k;+------------+---------------------+----------------+ | date | date_time | time_stamp | +------------+---------------------+----------------+ | 1998-12-31 | 1998-12-31 23:59:59 | 19981231235959 | | 1999-01-01 | 1999-01-01 00:00:00 | 19990101000000 | | 1999-09-09 | 1999-09-09 23:59:59 | 19990909235959 | | 2000-01-01 | 2000-01-01 00:00:00 | 20000101000000 | | 2000-02-28 | 2000-02-28 00:00:00 | 20000228000000 | | 2000-02-29 | 2000-02-29 00:00:00 | 20000229000000 | | 2000-03-01 | 2000-03-01 00:00:00 | 20000301000000 | | 2000-12-31 | 2000-12-31 23:59:59 | 20001231235959 | | 2001-01-01 | 2001-01-01 00:00:00 | 20010101000000 | | 2004-12-31 | 2004-12-31 23:59:59 | 20041231235959 | | 2005-01-01 | 2005-01-01 00:00:00 | 20050101000000 | | 2030-01-01 | 2030-01-01 00:00:00 | 20300101000000 | | 2050-01-01 | 2050-01-01 00:00:00 | 00000000000000 | +------------+---------------------+----------------+ 13 rows in set (0.00 sec)
Das zeigt, dass die DATE- und
DATETIME-Typen für zukünftige Datumsangaben
keine Probleme bereiten werden (sie handhaben Datumsangaben bis
zum Jahr 9999).
Der TIMESTAMP-Typ, der zur Speicherung der
aktuellen Zeit benutzt wird, hat nur einen Bereich bis zu
2030-01-01. TIMESTAMP hat
einen Bereich von 1970 bis
2030 auf 32-Bit-Maschinen
(vorzeichenbehafteter Wert). Auf 64-Bit-Maschinen handhabt
dieser Spaltentyp bis zu 2106
(vorzeichenloser Wert).
Obwohl MySQL Jahr-2000-kompatibel ist, sind Sie dafür verantwortlich, mehrdeutige Eingaben zu vermeiden. Siehe Abschnitt 2.2.4, „Jahr-2000-Konformität“ wegen der Regeln, die MySQL anwendet, wenn mehrdeutige Datumsangaben gemacht werden (Datumsangaben, die zweistellige Jahreswerte verwenden).
MySQL AB ist das Unternehmen der MySQL Gründer
und Hauptentwickler. MySQL AB wurde ursprünglich in Schweden von
David Axmark, Allan Larsson und Michael Monty
Widenius gegründet.
Alle Entwickler des MySQL Servers sind Angestellte dieses Unternehmens. Wir sind eine virtuelle Firma mit Mitarbeitern, die über die ganze Welt verstreut in aller Herren Länder sitzen. Der Hauptteil unserer Kommunikation untereinander, mit unseren Anwendern, Unterstützern und Partnern wird über das Internet abgewickelt
Wir haben uns der Entwicklung und Verbreitung des MySQL Datenbankservers verschrieben. MySQL hält das Copyright der MySQL Quelltexte, des MySQL Logos und dieses Handbuchs.. See Abschnitt 2.2, „Was ist MySQL?“.
Die MySQL-Kernwerte zeigen unsere Verpflichtung gegenüber MySQL und Open Source.
Wir wollen, dass MySQL folgendes ist:
Die beste und meist benutzte Datenbank der Welt.
Verfügbar für alle. Alle sollen sich MySQL leisten können.
Leicht zu benutzen.
Kontinuierlich verbessert, trotzdem immer schnell und sicher bleibend.
Es soll Spass machen, MySQL zu benutzen und zu verbessern.
Frei von Bugs.
MySQL AB und die Leute von MySQL AB:
Verbreiten die Open-Source-Philosophie und unterstützen die Open-Source-Community.
Bemühen sich, gute Bürger zu sein.
Bevorzugen Partner, die unsere Werte und unsere Geisteshaltung teilen.
Beantworten Mail und geben Support.
Sind ein virtuelles Unternehmen, das mit anderen im Netzwerk zusammenarbeitet (networking).
Arbeiten gegen Software-Patente.
Eine der uns häufig gestellten Fragen ist: Wie kann man von etwas leben, das man kostenlos abgibt? Hier ist die Antwort: MySQL AB verdient Geld mit Support, Dienstleistungen, kommerziellen Lizenzen und Lizenzgebühren, das wir dazu verwenden, die Produktentwicklung zu finanzieren und die MySQL-Geschäftsfelder auszubauen.
Unser Unternehmen läuft seit der Gründung profitabel. Im Oktober 2001 akzeptierten wir eine Risikokapitalfinanzierung durch führende skandinavische Investoren und eine Handvoll Business-Angels. Die Investitionen werden genutzt, um unser Geschäftsmodell auf solide Füße zu stellen und eine Grundlage für nachhaltiges Wachstum zu schaffen.
MySQL AB gehört den Gründern und Haupt-Entwicklern der
MySQL-Datenbank und wird von ihnen betrieben. Die Entwickler
fühlen sich verpflichtet, Kunden und anderen Benutzern
Support zu bieten, um mit deren Bedürfnissen und Problemen in
Kontakt zu bleiben. Unser gesamter Support wird durch
qualifizierte Entwickler geleistet. Wirklich schwierige Fragen
werden von Michael Monty Widenius
beantwortet, der der erste Entwickler des MySQL-Servers ist.
See Abschnitt 2.4.1, „Support den MySQL AB anbietet“.
Um Support unterschiedlicher Grade zu bestellen, besuchen Sie
bitte die Bestellseite unter
https://order.mysql.com/.
Wenn Sie nur beschränkten Zugriff auf das Internet haben,
setzen Sie sich bitte mit unserem Vertrieb unter
<sales@mysql.com> in Verbindung.
MySQL AB führt Schulungen zu MySQL und verwandten Themen weltweit durch. Wir bieten sowohl offene Kurse als auch In-house-Trainings an, die auf die speziellen Bedürfnisse Ihres Unternehmens zugeschnitten sind. MySQL-Schulungen werden auch durch unsere Partner durchgeführt, die Authorised MySQL Training Center.
Unsere Schulungsmaterialien benutzen dieselben Beispiel-Datenbanken wie unsere Dokumentation und unsere Beispiel-Applikationen und werden ständig aktualisiert, um den Entwicklungsstand der neusten MySQL-Version widerzuspiegeln. Unsere Trainer erhalten Rückhalt vom Entwicklungsteam, um die Trainingsqualität und die kontinuierliche Entwicklung des Schulungsmaterials sicherzustellen. Das stellt auch sicher, dass keine während der Kurse aufgetretenen Fragen unbeantwortet bleiben.
Wenn Sie an unseren Schulungen teilnehmen, können Sie sicher sein, die Ziele zu erreichen, die Sie mit Ihren MySQL-bezogenen Applikationen anstreben. Ausserdem haben Sie folgende Vorteile:
Sie sparen Zeit.
Sie verbessern die Performance Ihrer Applikation(en).
Sie verringern die Notwendigkeit zusätzlicher Hardware, was Kosten spart.
Sie verbessern Ihre Sicherheit.
Sie erhöhen die Zufriedenheit Ihrer Kunden und Mitarbeiter.
Sie bereiten sich auf die MySQL-Zertifizierung vor.
Wenn Sie an unseren Schulungen Interesse als möglicher
Teilnehmer oder Trainingspartner haben, besuchen Sie bitte die
Seite unter
http://www.mysql.com/training/.
Wenn Sie nur beschränkten Zugriff auf das Internet haben,
setzen Sie sich bitte mit unserem Trainingspersonal unter
<training@mysql.com> in Verbindung.
Die Veröffentlichung des MySQL-Zertifizierungsprogramms ist
für 2002 geplant. Details finden Sie unter
http://www.mysql.com/training/certification.html.
Wenn Sie stets die neusten Informationen über das
MySQL-Zertifizierungsprogramm haben wollen, schicken Sie bitte
eine E-Mail an <certification@mysql.com>.
MySQL AB und seine authorisierten Partner bieten Benutzern des MySQL-Servers und denen, die ihn in ihre Software einbetten wollen, Beratungsleistungen, weltweit.
Unsere Berater können Ihnen helfen, Ihre Datenbanken zu entwerfen und zu optimieren, effiziente Anfragen zu konstruieren, Ihre Plattform auf optimale Performance zu tunen, Migrationsprobleme zu lösen, Replikation aufzusetzen, robuste transaktionale Applikationen zu bauen und vieles mehr. Wir helfen auch Kunden dabei, den MySQL-Server für den Großflächigen Einsatz in ihre Produkte und Applikationen einzubauen.
Unsere Berater arbeiten in enger Kooperation mit unserem Entwicklungsteam, was die technische Qualität unserer Dienstleistungen sicherstellt. Beratungsaufgaben erstrecken sich von zweitägigen Power-Start-Sessions bis zu Projekten, die Wochen und Monate dauern. Unsere Kompetenz deckt nicht nur den MySQL-Server ab, sondern auch Programmier- und Skripting-Sprachen wie PHP, Perl und andere.
Wenn Sie an unseren Beratungsleistungen interessiert sind oder
ein Consulting-Partner werden wollen, besuchen Sie bitte
unsere Seite unter
http://www.mysql.com/consulting/.
Wenn Sie nur beschränkten Zugriff auf das Internet haben,
setzen Sie sich bitte mit unserem Beratungspersonal unter
<consulting@mysql.com> in Verbindung.
Die MySQL-Datenbank wird unter der GNU General Public
License veröffentlicht (GPL).
Das bedeutet, dass die MySQL-Software kostenlos unter der GPL
benutzt werden darf. Wenn Sie nicht an die GPL-Bedingungen
gebunden sein wollen (was in der Folge bedeutet, dass auch
Ihre eigenen Applikationen GPL werden), können Sie eine
kommerzielle Lizenz für dasselbe Produkt unter
https://order.mysql.com/
erwerben.
Weil MySQL AB das Copyright am MySQL-Server besitzt, können
wir eine duale Lizensierung einsetzen, was
heißt, dass dasselbe Produkt sowohl unter der GPL als auch
unter einer kommerziellen Lizenz erhältlich ist. Das berührt
in keiner Weise die Verpflichtung von MySQL AB gegenüber
Open Source. Wegen Details, wann eine
kommerzielle Lizenz erforderlich ist, sehen Sie bitte unter
Abschnitt 2.4.4, „MySQL-Lizenzpolitik“ nach.
Wir verkaufen auch kommerzielle Lizenzen von
Open-Source-GPL-Software Dritter. Ein gutes Beispiel hierfür
ist der InnoDB-Tabellen-Handler, der
ACID-Unterstützung, Sperren auf Zeilenebene,
Wiederherstellung nach Abstürzen, Multiversionierung,
Fremdschlüsselunterstützung und vieles mehr bietet.
MySQL AB hat ein weltweites Partnerprogramm, dass
Schulungskurse, Support, Beratung, Lösungen, Publikationen
plus Weiterverkauf und Vertrieb von MySQL und verwandten
Produkten beinhaltet. Partner erscheinen unter
http://www.mysql.com/
auf der Website und erhalten das Recht, spezielle Versionen
der MySQL-Schutzmarken zu benutzen, um ihre Produkte zu
identifizieren und ihr Geschäft voranzutreiben. Wenn Sie
interessiert sind, ein MySQL-AB-Partner zu werden, schicken
Sie bitte eine E-Mail an <partner@mysql.com>.
Das Wort MySQL und das MySQL-Delphin-Logo
sind Schutzmarken von MySQL AB. See
Abschnitt 2.4.3, „MySQL-AB-Logos und -Schutzmarken“.
Die MySQL-Website
(http://www.mysql.com/)
ist bei Entwicklern und Benutzern beliebt. Im Oktober 2001
bedienten wir 10 Millionen Seitenanfragen (PageViews). Unsere
Besucher repräsentieren eine Gruppe, die Kaufentscheidungen
und Empfehlungen sowohl für Software als auch für Hardware
trifft. 12% unserer Besucher genehmigen Kaufentscheidungen,
lediglich 9% sind überhaupt nicht an Kaufentscheidungen
beteiligt. Mehr als 65% haben innerhalb des letzten halben
Jahres online eingekauft, 70% planen, in den nächsten Monaten
einzukaufen. Wenn Sie Interesse haben, Werbebanner auf unserer
Website
http://www.mysql.com/
zu schalten, setzen Sie sich bitte mit
<advertising@mysql.com> in Kontakt.
Die MySQL Website (http://www.mysql.com/) enthält die neusten Informationen über MySQL und MySQL AB.
Für Presseservice und Anfragen aller Art, die in unseren
Veröffentlichungen
(http://www.mysql.com/news/)
nicht behandelt werden, wenden Sie sich bitte an
<press@mysql.com>.
Zeitnahe, präzise Antworten auf technische Fragen erhalten Sie, wenn Sie unter order einen unserer Support-Verträge abschließen. MySQL-Support wird von den MySQL-Entwicklern geleistet, weshalb der Standard extrem hoch ist.
Informationen über MySQL Trainig erhalten Sie unter
http://www.mysql.com/training/.
Wenn Sie einen eingeschränkten Internetzugang haben,
kontaktieren Sie bitte unser Trainingspersonal unter
<training@mysql.com>. See
Abschnitt 2.3.1.2, „Training und Zertifizierung“.
Für Informationen über das MySQL Zertifizierungsprogramm
erhalten Sie unter
http://www.mysql.com/training/certification.html.
Wenn Sie weiterhin über das MySQL Zertifizierungsprogramm
informiert werden wollen, schreiben Sie eine E-Mail an
<certification@mysql.com>. See
Abschnitt 2.3.1.3, „Beratung“.
Kommerzielle Lizenzen können online unter
https://order.mysql.com/
abgewickelt werden. Dort finden Sie ausserdem Informationen
darüber, wie Sie ihre Bestellung per Fax erledigen können.
Wenn Sie Fragen bezüglich der Lizensierung haben, oder Sie
ein Angebot über eine größere Lizenzerteilung erhalten
wollen, füllen Sie bitte Das Kontaktformular auf unserer
Website
(http://www.mysql.com/)
aus, oder schicken Sie eine E-Mail an
<licensing@mysql.com> (für Lizenzfragen) oder an
<sales@mysql.com> (für Verkaufsinformationen).
See Abschnitt 2.4.4, „MySQL-Lizenzpolitik“.
Wenn Sie daran interessiert sind, ein Werbebanner auf unserer
Website
(http://www.mysql.com/)
zu schalten, schicken Sie bitte eine E-Mail an
<advertising@mysql.com>. See
Abschnitt 2.3.1.6, „Werbung“.
Wenn Sie ein Unternehmen vertreten, dass an einer
Partnerschaft mit MySQL interessiert ist, schicken Sie bitte
eine E-Mail an <partner@mysql.com>.
Für weitere Informationen über die MySQL
Schutzmarkenbestimmungen, beachten Sie bitte
http://www.mysql.com/company/trademark.html
oder kontaktieren Sie <trademark@mysql.com>.
See Abschnitt 2.4.3, „MySQL-AB-Logos und -Schutzmarken“.
Wenn Sie an einem der Jobs interessiert sind, die im
jobs-Abschnitt
aufgeführt sind, schicken Sie bitte eine E-Mail an
<jobs@mysql.com>. Bitte senden Sie ihre CV nicht
als Anhang an dieser mail mit, sondern fügen Sie sie lieber
am Ende ihrer mail als Klartext (plain text) ein.
Allgemeine Diskussionen mit vielen unserer Benutzer können Sie auf den entsprechenden Mailing-Listen führen.
Fehlerberichte (Auch Bugreporte genannt), sowie Fragen und
Kommentare, sollten an die Mailingliste
<mysql@lists.mysql.com> gehen. Wenn Sie ein
empfindliches Sicherheitsloch im MySQL Server gefunden haben,
sollten
Sie eine E-Mail an <security@mysql.com>
schreiben. See Abschnitt 2.6.2.3, „Wie man Bugs oder Probleme berichtet“.
Wenn Sie Benchmarkergebnis haben, die wir veröffentlichen
können, kontaktieren Sie uns unter
<benchmarks@mysql.com>.
Wenn Sie Vorschläge für Hinzufügungen oder Korrekturen
dieses Handbuchs haben, schicken Sie sie bitte an das
Handbuch-Team: <docs@mysql.com>.
Fragen zur Arbeitsweise oder zu Inhalten unserer
Website(http://www.mysql.com/)
stellen Sie bitte an <webmaster@mysql.com>.
Fragen über das MySQL Portal
(http://www.mysql.com/portal/)
können an <portals@mysql.com> geschickt werden.
Die Datenschutzbestimmungen von MySQL AB können Sie unter
http://www.mysql.com/company/privacy.html
einsehen. Für irgendwelche Fragen darüber, wenden Sie sich
bitte an <privacy@mysql.com>.
Allgemeine Informationsanfragen schicken Sie bitte an
<info@mysql.com>.
Dieser Abschnitt beschreibt die MySQL Support und Lizensierungsvereinbarungen
Wir versuchen, technischen Support in einem breiten und umfassenden Blickwinkel zu sehen. Fast jedes Problem im Zusammenhang mit MySQL-Software ist für uns wichtig, wenn es für Sie wichtig ist. Typischerweise suchen Kunden Hilfe dabei, wie man unterschiedliche Befehle und Dienstprogramme zum Funktionieren bringt, wie Performance-Flaschenhälse beseitigt werden können, wie man beschädigte Systeme repariert, wie sich Betriebssysteme oder Netzwerkkonfigurationen auf MySQL auswirken, wie man Datensicherung und Wiederherstellung optimal konfiguriert, wie man APIs benutzt usw. Unser Support deckt nur den MySQL-Server und unsere eigenen Dienstprogramme ab, nicht Produkte Dritter, die auf den MySQL-Server zugreifen, obwohl wir auch hierbei versuchen, zu helfen wo wir können.
Detaillierte Informationen über unsere unterschiedlichen
Support-Optionen finden Sie auf
https://order.mysql.com/,
wo auch Support-Verträge online bestellt werden können. Wenn
Sie nur beschränkten Zugriff auf das Internet haben, setzen Sie
sich mit unserem Vertrieb unter <sales@mysql.com>
in Verbindung.
MySQL AB besitzt das Copyright des
MySQL-Quellcodes, die MySQL-Logos und (registrierten)
Schutzmarken sowie dieses Handbuch. See
Abschnitt 2.3, „Was ist MySQL AB?“. Es gibt einige verschiedene
Lizenzen, die für MySQL-Distributionen relevant sind:
Der gesamte MySQL-spezifische Quelltext des Servers, die
mysqlclient-Bibliothek und der Client
sowie die GNU-readline-Bibliothek
unterliegen der GNU General Public License. See
Anhang G, GNU GENERAL PUBLIC LICENSE. Der Text dieser Lizenz
befindet sich in der Datei COPYING in
allen MySQL-Distributionen.
Die GNU-getopt-Bibliothek unterliegt der
GNU Lesser General Public License. Siehe
http://www.fsf.org/licenses/.
Einige Teile des Quelltextes (die
regexp-Bibliothek) werden von einem
Copyright in Berkeley-Art abgedeckt.
Ältere Versionen von (3.22 und früher) stehen unter einer strikteren Lizenz (http://www.mysql.com/products/mypl.html). Bitte beachten sie die Dokumentation der speziellen Version für weitere Informationen.
Das Handbuch steht nicht unter einer GPL-artigen Lizenz. Die Benutzung des Handbuchs unterliegt den folgenden Bestimmungen.
Die Konvertierung in andere Formate ist erlaubt, der Inhalt jedoch darf auf keinen Fall geändert oder bearbeitet werden.
Sie können eine gedruckte Version für Ihren Privatgebrauch erstellen.
Für alle anderen Zwecke, wie den Verkauf von gedruckten Kopien oder die Verwendung (auch in Teilen) des Handbuchs in anderen Veröffentlichungen, ist eine vorherige Vereinbarung mit MySQL AB erforderlich.
Bitte senden Sie eine E-Mail an
<docs@mysql.com> für weitere Informationen
oder wenn Sie daran interessiert sind, eine Übersetzung zu
erstellen.
Für Informationen darüber, wie die MySQL-Lizenzen in der Praxis angewendet werden, beachten Sie bitte Abschnitt 2.4.4, „MySQL-Lizenzpolitik“. Siehe auch Abschnitt 2.4.3, „MySQL-AB-Logos und -Schutzmarken“.
Internet Service Provider (ISP) hosten oft MySQL-Server für ihre Kunden. Aufgrund der GPL-Lizenz ist hierfür keine Lizensierung erforderlich.
Auf der anderen Seite ermutigen wir Leute, ISPs zu benutzen, die MySQL-Support haben, und das wird ihnen Vertrauen geben, dass ihr ISP im Falle von Problemen mit ihrer MySQL-Installation helfen wird, das Problem zu lösen (in manchen Fällen mit der Hilfe des MySQL-Entwicklungsteams).
Alle ISPs, die auf dem neuesten Stand der Dinge bleiben
wollen, sollten sich in die
announce-Mailing-Liste eintragen, um auf
der Hut zu sein vor schwerwiegenden Problemen, die für ihre
MySQL-Installationen relevant sein könnten.
Beachten Sie bitte, dass ein ISP ohne MySQL-Lizenz seinen Kunden zumindest Lesezugriff auf den Quelltext der MySQL-Installation geben sollte, damit die Kunden feststellen können, dass diese korrekt gepatcht ist.
Wenn Sie MySQL in Verbindung mit einem Webserver unter Unix betreiben, brauchen Sie nicht für eine Lizenz zu bezahlen.
Das gilt selbst dann, wenn Sie einen kommerziellen Webserver betreiben, der MySQL benutzt, weil Sie nicht selbst eine eingebettete MySQL-Version verkaufen. Dennoch bitten wir Sie, in einem solchen Fall MySQL-Support zu kaufen, weil MySQL Ihrem Unternehmen hilft.
Viele MySQL-Datenbankbenutzer wollen auf Ihren Websites, ihren
Büchern und Packungsprodukten das MySQL-AB-Delphin-Logo zeigen.
Wir begrüßen das und ermuntern dazu, weisen aber darauf hin,
dass das Wort MySQL und das
MySQL-Delphin-Logo Schutzmarken von MySQL AB sind und nur so
benutzt werden dürfen, wie in unserer Schutzmarken-Richtlinie
unter
http://www.mysql.com/company/trademark.html
festgelegt.
Das MySQL-Delphin-Logo wurde von der finnischen Werbeagentur Priority im Jahr 2001 entworfen. Der Delphin wurde als passendes Symbol für die MySQL-Datenbank gewählt, weil er schlau, schnell und schlank ist und mühelos durch die Daten-Ozeane navigiert. Ausserdem mögen wir Delphine.
Das Original-MySQL-Logo darf nur von Repräsentanten von MySQL AB und von Personen benutzt werden, die eine schriftliche Erlaubnis hierfür haben.
Wir haben einen Satz spezieller Logos für vorbehaltliche Benutzung angelegt, die von unserer Website unter http://www.mysql.com/press/logos.html herunter geladen werden können und von Dritten auf ihren Websites ohne schriftliche Erlaubnis von MySQL AB benutzt werden dürfen. Der Gebrauch dieser Logos ist - wie der Name anzeigt - nicht völlig uneingeschränkt, sondern unterliegt unseren Schutzmarken-Richtlinien, die Sie auf unserer Website finden. Sie sollten diese Richtlinien lesen, wenn Sie planen, die Logos zu benutzen. Die Anforderungen sind im Wesentlichen:
Benutzen Sie das gewünschte Logo von der http://www.mysql.com/- Site. Sie dürfen die Größe nach Ihren Bedürfnissen anpassen, aber keine Farben oder das Design ändern noch die Grafik in sonstiger Form verändern.
Heben Sie hervor, dass Sie - und nicht MySQL AB - der Betreiber und Eigner der Site ist, auf der die MySQL-Schutzmarke gezeigt wird.
Sie dürfen die Schutzmarke nicht auf eine Weise benutzen, die MySQL AB oder dem Wert der MySQL-AB-Schutzmarken schadet. Wir behalten uns das Recht vor, das Recht zur Benutzung der MySQL-AB-Schutzmarke zu widerrufen.
Wenn Sie die Schutzmarke auf einer Website benutzen, machen Sie sie anklickbar, wobei direkt nach http://www.mysql.com/ verlinkt wird.
Wenn Sie die MySQL-Datenbank unter GPL in einer Applikation benutzen, muss Ihre Applikation (i) Open Source sein, (ii) in der Lage sein, sich mit einem MySQL-Server zu verbinden.
Setzen Sie sich unter <trademark@mysql.com> mit
uns in Verbindung, um wegen spezieller Arrangements
anzufragen, die Ihren Bedürfnissen entsprechen.
In folgenden Fällen benötigen Sie eine schriftliche Erlaubnis von MySQL AB, bevor Sie die MySQL-Logos benutzen:
Wenn Sie irgend ein MySQL-AB-Logo irgendwo ausser auf Ihrer Website zeigen.
Wenn Sie irgend ein MySQL-AB-Logo ausser den oben erwähnten Logos zur vorbehaltlichen Benutzung auf Websites oder anderswo anzeigen.
Aus rechtlichen und kommerziellen Gründen müssen wir die Benutzung der MySQL-Schutzmarken auf Produkten, Büchern usw. beobachten. Üblicherweise verlangen wir eine Gebühr für das Anzeigen von MySQL-AB-Logos auf kommerziellen Produkten, weil wir der Meinung sind, das es vertretbar ist, dass einige der Erlöse für die Weiterentwicklung der MySQL- Datenbank zurückfließen.
MySQL-Partnerschafts-Logos dürfen nur von Unternehmen und Personen benutzt werden, die eine schriftliche Partnerschaftsvereinbarung mit MySQL AB haben. Partnerschaften beinhalten eine Zertifizierung als MySQL-Trainer oder -Berater. Sehen Sie bitte unter
Die formalen Bedingungen der GPL-Lizenz stehen unter Anhang G, GNU GENERAL PUBLIC LICENSE. Im Wesentlichen ist unsere Lizenzpolitik und die Interpretation der GPL wie folgt:
Beachten Sie bitte, dass ältere Versionen von MySQL immer noch einer strengeren Lizenz unterliegen. Sehen Sie in der Dokumentation der betreffenden Version wegen entsprechender Informationen nach. Wenn Sie eine kommerzielle Lizenz benötigen, weil die GPL-Lizenz nicht zu den Anforderungen Ihrer Applikation passt, können Sie eine Lizenz unter https://order.mysql.com/ kaufen.
Für normalen internen Gebrauch kostet MySQL nichts. Sie brauchen uns nichts zu bezahlen, wenn Sie nicht wollen.
Eine Lizenz wird benötigt:
Wenn Sie ein Programm, das nicht freie Software ist, mit Code des MySQL-Servers oder der Client-Programme verbinden, die den GPL-Copyrights unterliegen. Das ist zum Beispiel der Fall, wenn Sie MySQL als eingebetteten Server (Embedded Server) in Ihren Applikationen benutzen, oder wenn Sie dem MySQL-Server Erweiterungen hinzufügen, die nicht freie Software sind. In diesen Fällen würden Ihre Applikation bzw. Ihr Code ebenfalls GPL werden, weil die GPL in solchen Fällen wie ein Virus wirkt. Sie können dieses Problem vermeiden, wenn Sie den MySQL-Server mit einer kommerziellen Lizenz von MySQL AB erwerben. Siehe http://www.gnu.org/copyleft/gpl-faq.html.
Wenn Sie eine kommerzielle Applikation haben, die NUR mit MySQL funktioniert, und wenn Sie die Applikation zusammen mit dem MySQL-Server ausliefern. Wir betrachten so etwas als Einbindung, selbst wenn es über das Netzwerk geschieht.
Wenn Sie eine Distribution von MySQL besitzen und nicht den Quelltext für Ihre Kopie des MySQL-Servers zur Verfügung stellen, so wie es in der GPL-Lizenz festgelegt ist.
In Situationen, wo eine MySQL-Lizenz benötigt wird, brauchen Sie eine Lizenz pro Maschine, auf der der MySQL-Server läuft. Eine Mehrprozessor-Maschine zählt jedoch als eine einzelne Maschine, und es gibt keine Beschränkung hinsichtlich der Anzahl von MySQL-Servern, die auf einer Maschine laufen, oder hinsichtlich der Anzahl von Clients, die zur gleichen Zeit mit einem Server verbunden sind, der auf dieser Maschine läuft!
Falls Sie nicht sicher sind, ob für Ihre spezielle Benutzung von MySQL eine Lizenz erforderlich ist, lesen Sie diesen Abschnitt bitte nochmals, bevor Sie uns kontaktieren. See Abschnitt 2.3.1.7, „Kontaktinformationen“.
Wenn Sie eine MySQL-Lizenz benötigen, ist die Bezahlung am einfachsten, wenn Sie das Lizenzformular auf dem Secure-Server von MySQL unter https://order.mysql.com/ benutzen.
Präsentationen
MySQL AB begrüßt Verweise auf die MySQL-Datenbank, aber das
Wort MySQL ist eine Schutzmarke von MySQL
AB. Deshalb müssen Sie der ersten oder deutlichsten
Erwähnung des Worts MySQL das
Schutzmarken-Symbol TM hinzufügen, und wo
angebracht deutlich machen, dass MySQL eine
Schutzmarke von MySQL AB ist. Details entnehmen Sie bitte
unserer Schutzmarken-Richtlinie unter
http://www.mysql.com/company/trademark.html.
Dateline: 16. Oktober 2001, Uppsala, Schweden
Lange durch MySQL AB angekündigt und lange von unseren Benutzern erwartet: Der MySQL-Server 4.0 ist jetzt in der Alpha-Version zum Herunterladen von http://www.mysql.com/ und unseren Mirrors verfügbar.
Die neuen Haupt-Features des MySQL-Servers 4.0 sind eng mit unserem bestehenden Geschäft und den Community-Nutzern verzahnt. Durch ihn wird die MySQL-Datenbank-Software als Lösung für geschäftskritische Schwerlast-Datenbanksysteme verbessert. Weitere neue Features zielen auf die Benutzer eingebetteter Datenbanken.
Das Erscheinen des MySQL-Servers 4.0 wird in mehreren Schritten erfolgen, wobei die erste Version 4.0.0 genannt wird und bereits die meisten neuen Features enthält. Zusätzliche Features werden in die Versionen 4.0.1, 4.0.2 usw. eingebaut, höchstwahrscheinlich innerhalb weniger Monate. MySQL 4.0 wird als Beta gekennzeichnet. In MySQL 4.1 werden dann weitere neue Features hinzugefügt. Es wird angestrebt, das Alpha-Release Anfang 2002 herauszubringen.
Es wird nicht empfohlen, Produktionssysteme auf den MySQL-Server 4.0 umzustellen, bis dieser in der Beta-Version veröffentlicht wird. Selbst das anfängliche Release hat unsere ausgiebigen Tests ohne jegliche Fehler durchlaufen, auf allen Plattformen, auf denen wir testen. Wegen der großen Zahl neuer Features empfehlen wir daher den MySQL-Server selbst in der Alpha-Version für Entwicklungsarbeiten, wobei in Betracht gezogen werden kann, dass der MySQL-Server 4.0 das Stadium "stabil" erreichen wird, bevor Applikationen hiermit veröffentlicht werden, die jetzt im Entwicklungsstadium sind.
libmysqld macht den MySQL-Server für einen
erheblich ausgedehnten Bereich von Applikationen geeignet. Wenn
man die eingebettete MySQL- Server-Bibliothek benutzt, kann man
den MySQL-Server in unterschiedlichste Applikationen und
elektronische Geräte einbetten, bei denen der Endbenutzer
keinerlei Ahnung davon hat, dass ihnen eine Datenbank unterlegt
ist. Der eingebettete MySQL-Server ist ideal für Benutzung
hinter den Kulissen in Internet-Geräten, öffentlichen Kiosken,
schlüsselfertigen Hardware-/Software-Einheiten,
Hochlast-Internet- Servern oder Datenbanken, die auf CD-ROM
vertrieben werden.
Viele Benutzer von eingebettetem MySQL können von der dualen Lizensierung der MySQL-Software profitieren. Neben der GPL-Lizenz sind auch kommerzielle Lizenzen für diejenigen verfügbar, die nicht an die GPL gebunden sein wollen. Die eingebettete MySQL-Bibliothek benutzt dieselbe Schnittstelle wie die normale Client-Bibliothek und ist daher angenehm und leicht zu benutzen. See Abschnitt 9.4.9, „libmysqld, die eingebettete MySQL-Server-Bibliothek“.
Version 4.0 erhöht die Geschwindigkeit des
MySQL-Servers in einigen Bereichen noch weiter,
zum Beispiel bei Massen-INSERTs, beim
Suchen auf komprimierten Indexen, der Erzeugung von
FULLTEXT-Indexen oder auch bei
COUNT(DISTINCT).
Der Tabellen-Handler InnoDB wird jetzt
als Feature des standardmäßigen MySQL-Servers angeboten
und enthält vollständige Unterstützung für
Transaktionen und Sperren auf
Zeilenebene.
Der MySQL-Server 4.0 unterstützt sichere Kommunikation
zwischen Client und Server, wodurch die Sicherheit gegen
böswilliges Eindringen und unbefugten Zugriff erheblich
erhöht wird. Bei Web-Applikationen, die ein Grundpfeiler
der MySQL-Benutzung sind, konnten Web-Entwickler immer schon
SSL verwenden, um den Verkehr zwischen Endbenutzer-Browser
und der Web-Applikation zu sichern, sei sie nun in PHP,
Perl, ASP oder mit irgend einem anderen
Web-Entwicklungswerkzeug geschrieben. Der Verkehr zwischen
dem Entwicklungswerkzeug und dem mysqld-Serverprozess konnte
bislang aber nur dadurch gesichert werden, dass die Prozesse
auf Computern innerhalb derselben Firewall residierten. Ab
MySQL-Server 4.0 kann der
mysqld-Server-Daemon-Prozess selbst
Secure Sockets Layer
(SSL) benutzen, was ihn in die Lage
versetzt, eine sichere Datenübertragung zwischen einer
MySQL-Datenbank und beispielsweise einer Windows-Applikation
ausserhalb der Firewall aufzubauen.
Unsere deutschen, österreichischen und schweizerischen Benutzer werden bemerken, dass es einen neuen Zeichensatz latin_de gibt, der die deutsche Sortierreihenfolge beinhaltet, indem deutsche Umlaute in derselben Sortierung erscheinen wie bei deutschen Telefonbüchern üblich.
Zu den Features, die die Migration von
anderen Datenbanksystemen zum MySQL-Server erleichtern,
gehören TRUNCATE TABLE (wie in Oracle)
und IDENTITY a1s Synonym für automatisch
hochgezählte Schlüssel (wie in Sybase). viele Benutzer
werden sich auch darüber freuen, dass der MySQL-Server
jetzt das UNION-Statement unterstützt,
ein lang erwartetes Standard-SQL-Feature.
Bei der Erstellung neuer Features für neue Benutzer haben
wir die Gemeinschaft treuer Benutzer nicht vergessen. Es
gibt jetzt Multi-
Tabellen-DELETE-Statements. Durch das
Hinzufügen von Unterstützung für symbolisches
Verknüpfen von MyISAM auf
Tabellenebene (und nicht nicht - wie bisher - auf
Datenbankebene), sowie durch das vorgabemäßige Anschalten
der Verknüpfungen unter Windows hoffen wir zeigen zu
können, dass wir Verbesserungsvorschläge ernst nehmen.
Funktionen wie SQL_CALC_FOUND_ROWS und
FOUND_ROWS() ermöglichen herauszufinden,
wie viele Zeilen eine Anfrage ohne eine
LIMIT-Klausel zurückgegeben hätte.
Für die kommenden Releases des MySQL-Servers 4.0 (4.0.1, 4.0.2 usw.) können Sie folgende Features erwarten, die noch in der Entwicklung sind:
Benutzer des MySQL-Servers für geschäftskritische
Hochlast-Anwendungen werden die Ergänzungen unseres
Replikationssystems und unsere Online- "Hot"-Datensicherung
begrüßen. Spätere Versionen von 4.0 werden
absturzsichere Replikation beinhalten,
die es bereits in Version 4.0.0 gibt, sowie den
LOAD DATA FROM MASTER-Befehl, der bald
das Aufsetzen von Slaves automatisieren wird.
online backup wird das Hinzufügen eines
neuen Replikations-Slaves erleichtern, ohne dass man den
Master herunterfahren muss, und es gibt auf Systemen mit
vielen Aktualisierungen nur geringe
Geschwindigkeitseinbussen.
Als Bequemlichkeits-Feature für Datenbank-Administratoren wird hinzugefügt, dass mysqld-Parameter (Startoptionen) bald ohne das Herunterfahren des Servers gesetzt werden können.
Die neuen Eigenschaften des MySQL-Servers 4.0 für die
Volltext- (FULLTEXT)-Suche ermöglichen
die FULLTEXT-Indexierung großer Texte
sowohl mit binärer wie auch mit natürlichsprachiger
Suchlogik. Benutzer können minimale Wortlängen anpassen
und ihre eigenen Stopp-Wort-Listen in jeder menschlichen
Sprache festlegen, wodurch gänzlich neue Applikationen
ermöglicht werden, die auf dem MySQL-Server aufbauen.
Viele Applikationen mit starkem Lesezugriff werden durch die
noch weiter erhöhte Geschwindigkeit des neu geschriebenen
Schlüssel-Caches profitieren.
Viele Entwickler wird auch die
MySQL-Befehlshilfe im Client freuen.
Intern wird durch das neue .frm-Dateiformat für
Tabellendefinitionen in MySQL-Server 4.0 die Grundlage für neue
Features in MySQL-Server 4.1 gelegt, beispielsweise
verschachtelte Unterabfragen,
gespeicherte Prozeduren und
Fremdschlüssel- Integritätsregeln, die ganz
oben auf der Wunschliste vieler unserer Kunden stehen. Daneben
werden auch einfachere Erweiterungen wie Multi-
Tabellen-UPDATE-Statements hinzugefügt.
Nach diesen Ergänzungen werden Kritiker des MySQL-Datenbankservers es noch schwerer haben, auf Schwächen des MySQL-Datenbank-Managementsystems hinzuweisen. MySQL, das seit langem für seine Stabilität, Geschwindigkeit und Einfachheit der Benutzung bekannt ist, wird dann den Anforderungen sehr anspruchsvoller Käufer genügen.
Die MySQL-Portale (http://www.mysql.com/portal/) auf unserer Website bieten ein breites Spektrum MySQL-bezogener Informationen und Links. Sie sind so aufgebaut, dass Sie leicht die Dinge finden, die Sie interessieren.
Sie können sich als Benutzer registrieren. In diesem Fall können Sie alle Dinge in den Portalen kommentieren und bewerten und auch selbst Dinge beisteuern. Bei der Registrierung können Sie auch angeben, ob und - wenn ja - welche Newsletter aus welchen Kategorien Sie beziehen wollen.
Einige der momentanen MySQL-Portal-Kategorien:
Bücher Hier finden Sie alle möglichen MySQL- oder Computer-bezogenen Bücher, die Sie kommentieren, bewerten oder kaufen können. Während dieses Handbuch (insbesondere die Online-Version) immer noch der richtige Platz für aktuellste technische Informationen ist, ist sein vorrangiges Ziel, alles zu enthalten, was man über das MySQL-Datenbanksystem wissen kann. Manchmal ist es nett, ein gebundenes Buch zu haben, dass man im Bett oder auf Reisen lesen kann. Wenn Sie ein Buch über die angegebenen Hyperlinks kaufen, tragen Sie zur Entwicklung der MySQL-Software bei.
Entwicklung Dieses Portal hat Links auf Seiten, die den MySQL-Server für unterschiedliche Zwecke benutzen, mit einer Beschreibung jeder Site. Diese Informationen können Ihnen eine gute Vorstellung davon geben, wer MySQL-Datenbank-Software benutzt und wie der MySQL-Server ihre Anforderungen erfüllt. Teile Sie uns auch Ihre Site oder Erfolgsgeschichte mit!
Software Hier finden Sie eine Vielzahl von Applikationen und Wrappern, die den MySQL-Server benutzen, die Sie auch herunter laden können.
Distributionen Hier finden Sie die verschiedenen Linux-Distributionen und weitere Software-Pakete, die die MySQL-Software enthalten.
Berater Hier finden Sie Informationen über MySQL-Berater.
Partner Hier finden Sie alle MySQL-Partner.
Dieser Abschnitt führt Sie in die MySQL-Mailing-Listen ein und zeigt einige Richtlinien und ihre Benutzung auf.
Um die MySQL-Haupt-Mailing-Liste zu abonnieren, schicken Sie
eine Nachricht an die E-Mail-Adresse
<mysql-subscribe@lists.mysql.com>.
Um sich aus der MySQL-Haupt-Mailing-Liste auszutragen,
schicken Sie eine Nachricht an die E-Mail-Adresse
<mysql-unsubscribe@lists.mysql.com>.
Von Bedeutung ist nur die Adresse, unter der Sie Ihre Nachrichten abschicken. Betreffzeile und Text der Nachricht werden ignoriert.
Wenn Ihre Antwortadresse nicht gültig ist, können Sie Ihre
Adresse explizit angeben. Fügen Sie einen Bindestrich zum
Abonnement- oder Abmelde-Kommando hinzu, gefolgt von Ihrer
Adresse, wobei das ‘@’-Zeichen
in Ihrer Adresse durch ‘=’
ersetzt wird. Um sich zum Beispiel mit
your_name@host.domain einzutragen, schicken
Sie eine Nachricht an
mysql-subscribe-your_name=host.domain@lists.mysql.com.
Mails an <mysql-subscribe@lists.mysql.com> oder
<mysql-unsubscribe@lists.mysql.com> werden
automatisch vom ezmlm Mailing-Listen-Prozessor bearbeitet.
Informationen über ezmlm sind auf
The ezmlm Website
verfügbar.
Um eine Nachricht an die Liste selbst zu schicken, schicken
Sie eine Mail an mysql@lists.mysql.com.
Schicken aber bitte keine Mail an
<mysql@lists.mysql.com>, die das Abonnieren oder
Austragen betrifft, denn Mails an diese Adresse werden
automatisch an tausende anderer Benutzer verteilt.
Wenn Ihre lokale Site viele Abonnenten für
<mysql@lists.mysql.com> hat, sollten Sie evtl.
eine lokale Mailing-Liste einrichten, so dass Nachrichten, die
von lists.mysql.com an Ihre Site gesandt
werden, an die lokale Liste verteilt werden. In solchen
Fällen wenden Sie sich bitte an Ihre Systemadministrator, um
zur lokalen Mailing-Liste hinzugefügt oder aus ihr gelöscht
zu werden.
Wenn Sie wollen, dass der Traffic einer Mailing-Liste in eine
separate Mailbox Ihres E-Mail-Programms geleitet wird, setzen
Sie einen Filter, der auf die E-Mail-Header (Kopfdaten)
reagiert. Sie können dazu entweder den
List-ID:- oder den
Delivered-To:-Header benutzen, um die
Listennachrichten zu erkennen.
Die folgenden MySQL-Mailing-Listen existieren:
<announce-subscribe@lists.mysql.com>
announce
Diese Liste kündigt neue Versionen von MySQL und verwandter Programme an. Sie hat geringen Traffic; alle MySQL-Benutzer sollten sie abonnieren.
<mysql-subscribe@lists.mysql.com>
mysql
Die Hauptliste für allgemeine MySQL-Diskussionen. Bitte beachten Sie, dass bestimmte Themen besser in spezialisierteren Listen diskutiert werden. Wenn Sie an die falsche Liste posten, erhalten Sie vielleicht keine Antwort!
<mysql-digest-subscribe@lists.mysql.com>
mysql-digest
Die mysql-Liste in Digest-Form
(zusammengefasst). Anstelle individueller Nachrichten wird
einmal pro Tag eine große Mail mit allen Nachrichten
dieses Tages geschickt.
<bugs-subscribe@lists.mysql.com>
bugs
An diese Liste sollte Sie ausschließlich komplette,
wiederholbare Bug-Berichte schicken, indem Sie das
mysqlbug-Skript benutzen. (Wenn Sie
unter Windows arbeiten, sollten Sie eine Beschreibung des
Betriebssystems und der MySQL-Version hinzufügen.)
Vorzugsweise sollten Sie den Problemfall mit der letzten
stabilen oder Entwicklungs-Version von MySQL testen, bevor
Sie den Bericht posten! Jeder sollte in der Lage sein, den
Bug zu wiederholen, indem einfach mysql test <
Skript auf den beigefügten Testfall angewandt
wird. Alle Bugs, die auf dieser Liste gepostet werden,
werden im nächsten MySQL-Release behoben oder
dokumentiert! Wenn nur kleinere Code-Änderungen betroffen
sind, werden wir zusätzlich ein Patch bereitstellen, das
das Problem behebt.
<bugs-digest-subscribe@lists.mysql.com>
bugs-digest
Die Digest-Version (zusammengefasst) der
bugs-Liste.
<internals-subscribe@lists.mysql.com>
internals
Eine Liste für Leute, die am MySQL-Code arbeiten. Auf dieser Liste kann man auch die MySQL-Entwicklung diskutieren und Patches posten.
<internals-digest-subscribe@lists.mysql.com>
internals-digest
Die Digest-Version (zusammengefasst) der
internals-Liste.
<java-subscribe@lists.mysql.com>
java
Diskussionen über MySQL und Java, hauptsächlich über JDBC-Treiber.
<java-digest-subscribe@lists.mysql.com>
java-digest
Eine java-Liste.
<win32-subscribe@lists.mysql.com>
win32
Alles betreffend MySQL auf Microsoft-Betriebssystemen wie Win95, Win98, NT, XP, und Win2000.
<win32-digest-subscribe@lists.mysql.com>
win32-digest
Die Digest-Version (zusammengefasst) der
win32-Liste.
<myodbc-subscribe@lists.mysql.com>
myodbc
Alles betreffend ODBC-Verbindungen zu MySQL.
<myodbc-digest-subscribe@lists.mysql.com>
myodbc-digest
Die Digest-Version (zusammengefasst) der
myodbc-Liste.
<plusplus-subscribe@lists.mysql.com>
plusplus
Alles, was das Programmieren mit der C++-API von MySQL betrifft.
<plusplus-digest-subscribe@lists.mysql.com>
plusplus-digest
Die Digest-Version (zusammengefasst) der
plusplus-Liste.
<msql-mysql-modules-subscribe@lists.mysql.com>
msql-mysql-modules
Eine Liste zur Perl-Unterstützung in MySQL. msql-mysql-modules
<msql-mysql-modules-digest-subscribe@lists.mysql.com>
msql-mysql-modules-digest
Die Digest-Version (zusammengefasst) der
msql-mysql-modules-Liste.
Alle Listen abonnieren Sie - und tragen sich wieder aus - auf
dieselbe Art wie oben beschrieben. Tragen Sie in Ihre Mail zum
Abonnieren oder Austragen die entsprechende Mailing-Liste ein
anstelle von mysql. Um sich zum Beispiel
für die myodbc-Liste einzutragen, schicken
Sie eine Nachricht an
<myodbc-subscribe@lists.mysql.com> oder
<myodbc-unsubscribe@lists.mysql.com>.
Wenn Sie keine Antwort auf Ihre Fragen von der Mailing-Liste erhalten, ist eine Option, für den Support von MySQL AB zu bezahlen, was Sie in direkten Kontakt mit den MySQL-Entwicklern bringt. See Abschnitt 2.4.1, „Support den MySQL AB anbietet“.
Die folgende Tabelle listet einige Mailing-Listen in anderen Sprachen als englisch auf. Beachten Sie, dass diese nicht von MySQL AB unterhalten werden. Daher können wir nicht für die Qualität dieser Listen garantieren.
<mysql-france-subscribe@yahoogroups.com>
Eine französische Mailing-Liste<list@tinc.net> Eine koreanische
Mailing-Liste
Schicken Sie eine E-Mail mit dem Betreff
subscribe mysql your@email.address an
diese Liste.
<mysql-de-request@lists.4t2.com>
Eine deutsche Mailing-Liste
Schicken Sie eine E-Mail mit dem Betreff
subscribe mysql-de your@email.address
an diese Liste. Informationen über diese Liste finden Sie
unter
http://www.4t2.com/mysql.
<mysql-br-request@listas.linkway.com.br>
Eine portugiesische Mailing-Liste.
Schicken Sie eine E-Mail mit dem Betreff
subscribe mysql-br your@email.address
an diese Liste.
<mysql-alta@elistas.net> Eine
spanische Mailing-Liste.
Schicken Sie eine E-Mail mit dem Betreff
subscribe mysql your@email.address an
diese Liste.
Bevor Sie einen Bug berichten oder eine Frage stellen, tun Sie bitte folgendes:
Suchen Sie im MySQL-Online-Handbuch: http://www.mysql.com/documentation/manual.php Wir bemühen uns, das Handbuch aktuell zu halten, indem wir es häufig mit Lösungen für neu bekannt gewordene Probleme aktualisieren!
Durchsuchen Sie die MySQL-Mailing-Listen-Archive: http://www.mysql.com/documentation/
Sie können ausserdem http://www.mysql.com/search.html benutzen, um alle Webseiten zu durchsuchen (inklusive des Handbuchs), die unter http://www.mysql.com/ zu finden sind.
Wenn Sie weder im Handbuch noch in den Archiven eine Antwort
finden können, versuchen Sie es mit Ihrem lokalen
MySQL-Experten. Wenn Sie immer noch keine Antwort auf Ihre
Frage finden, lesen Sie den nächsten Abschnitt über die
Mailing-Listen unter <mysql@lists.mysql.com>.
Einen guten Bug-Bericht zu schreiben braucht Geduld, aber es gleich beim ersten Mal richtig zu machen spart Ihnen und uns Zeit. Ein guter Bug-Bericht enthält einen kompletten Testfall für den Bug, der es sehr wahrscheinlich macht, dass wir ihn im nächsten Release beheben. Dieser Abschnitt hilft Ihnen, Ihren Bericht korrekt zu schreiben, damit Sie Ihre Zeit nicht damit verschwenden, etwas zu schreiben, was uns wenig oder gar nicht weiterhilft.
Wir ermutigen jeden, das mysqlbug-Skript zu
benutzen, um einen Bug-Bericht anzufertigen (oder einen
Bericht über irgendein anderes Problem), falls das möglich
ist. Der mysqlbug findet sich im
Skripts-Verzeichnis der
Quelldistribution, bzw. im
bin-Verzeichnis der Binärdistribution,
im Verzeichnis unterhalb Ihres
MySQL-Installationsverzeichnisses. Falls es Ihnen nicht
möglich ist, mysqlbug zu benutzen, sollten
Sie trotzdem alle notwendigen Informationen mitliefern, die in
diesem Abschnitt aufgeführt sind.
Das mysqlbug-Skript hilft Ihnen, einen
Bericht zu erstellen, der viele der folgenden Informationen
automatisch einschließt, aber falls etwas Wichtiges fehlt,
fügen Sie es bitte Ihrer Nachricht hinzu! Bitte lesen Sie
diesen Abschnitt sorgfältig und stellen Sie sicher, dass alle
hier beschriebenen Informationen in Ihrem Bericht enthalten
sind.
Für gewöhnlich sollten Sie Ihren Bug-Bericht und Probleme an
<mysql@lists.mysql.com> schicken. Wenn Sie einen
Testfall erzeugen können, der den Bug klar demonstriert,
sollten Sie ihn an die
<bugs@lists.mysql.com>-Liste schicken. Beachten
Sie, dass Sie nur einen kompletten, nachvollziehbaren
Bug-Bericht an diese Liste schicken sollten, indem Sie das
mysqlbug-Skript benutzen. Falls Sie unter
Windows arbeiten, sollten Sie eine Beschreibung des
Betriebssystems und der MySQL-Version hinzufügen.
Vorzugsweise sollten Sie den Problemfall mit der letzten
stabilen oder Entwicklungs-Version von MySQL testen, bevor Sie
den Bericht posten! Jeder sollte in der Lage sein, den Bug zu
wiederholen, indem einfach mysqltest <
Skript auf den beigefügten Testfall angewandt wird.
Alle Bugs, die auf dieser Liste gepostet werden, werden im
nächsten MySQL-Release behoben oder dokumentiert! Wenn nur
kleinere Code-Änderungen betroffen sind, werden wir
zusätzlich ein Patch bereitstellen, das das Problem behebt.
Denken Sie daran, dass es immer möglich ist, auf eine Nachricht zu antworten, die zu viele Informationen enthält, aber nicht immer auf eine, die zu wenige Informationen enthält. Oft lassen Leute Fakten aus, weil sie denken, die Ursache eines Probleme zu kennen und annehmen, dass einige Details nicht von Wichtigkeit sind. Ein gutes Prinzip ist folgendes: Falls Sie im Zweifel sind, ob Sie etwas Bestimmtes mitteilen sollten, teilen Sie es mit! Es ist tausendmal schneller und weniger ärgerlich, ein paar Zeilen mehr in Ihrem Bericht zu schreiben, als gezwungen zu sein, noch einmal zu fragen und auf die Antwort zu warten, weil Sie beim ersten Mal nicht genug Informationen geliefert haben.
Die häufigste Fehler besteht darin, dass Leute die Versionsnummer der MySQL-Distribution, die sie benutzen nicht angeben, oder vergessen anzugeben, auf welcher Plattform sie MySQL installiert haben (inklusive der Betriebssystem-Version). Diese Informationen sind äußerst relevant, und in 99 von 100 Fällen ist der Bug-Bericht ohne sie nutzlos! Sehr oft erhalten wir Fragen wie 'Warum funktioniert das bei mir nicht?', nur um herauszufinden, dass das beschriebene Feature nicht in der benutzten MySQL-Version implementiert war, oder dass der Bug, der im Bericht beschrieben wurde, bereits in einer neueren MySQL-Version behoben wurde. Manchmal ist der Fehler plattformabhängig; in solchen Fällen ist es praktisch unmöglich, irgend etwas zu beheben, ohne das Betriebssystem und die Versionsnummer des Betriebssystems zu kennen.
Denken Sie auch daran, Informationen über Ihren Compiler einzuschließen, falls sie MySQL selbst kompilieren. Oft finden Leute Fehler in Compilern und denken, dass das Problem MySQL-bezogen ist. Die meisten Compiler werden permanent weiter entwickelt und werden von Version zu Version besser. Um festzustellen, ob ein Problem von Ihrem Compiler abhängt oder nicht, müssen wir wissen, welcher Compiler benutzt wird. Beachten Sie, dass jedes Compiler-Problem als Bug-Bericht betrachtet und deshalb entsprechend berichtet werden sollte.
Es ist äußerst hilfreich, wenn eine gute Beschreibung des Probleme in Ihrem Bug-Bericht eingeschlossen ist, das heißt ein gutes Beispiel aller Dinge, die Sie getan haben, die zu dem Problem führten, sowie das Problem selbst. Die besten Bug-Berichte sind diejenigen, die ein komplettes Beispiel zeigen, wie man den Bug oder das Problem reproduzieren kann. See Abschnitt D.1.6, „Einen Testfall herstellen, wenn Sie Tabellenbeschädigung feststellen“.
Wenn ein Programm eine Fehlermeldung produziert, ist es sehr wichtig, diese in Ihren Bericht einzuschließen! Wenn wir in den Archiven der Programme suchen, ist es besser, wenn die Fehlernachricht exakt mit derjenigen übereinstimmt, die das Programm produziert. (Sogar Groß-/Kleinschreibung sollte berücksichtigt werden!) Sie sollten nie versuchen, sich daran zu erinnern, was die Fehlernachricht war; stattdessen sollten Sie die gesamte Nachricht per Kopieren und Einfügen in Ihrem Bericht unterbringen!
Wenn Sie ein Problem mit MyODBC haben, sollten Sie versuchen, eine MyODBC-Trace-Datei zu erstellen. See Abschnitt 9.3.7, „Probleme mit MyODBC berichten“.
Bitten denken Sie daran, dass viele Leute, die Ihren Bericht
lesen, dabei ein 80-Spalten-Anzeigegerät benutzen. Wenn Sie
Berichte oder Beispiele erzeugen, indem Sie das
mysql-Kommandozeilen-Werkzeug benutzen,
sollten Sie deshalb die --vertical-Option
(oder den \G-Statement-Begrenzer) für
Ausgaben benutzen, die ansonsten die verfügbare Anzeigebreite
überschreiten würden (zum Beispiel beim EXPLAIN
SELECT-Statement; siehe dazu das Beispiel weiter
unten).
Bitte schließen Sie folgende Informationen in Ihren
Bug-Bericht ein:
Die Versionsnummer der MySQL-Distribution, die Sie
benutzen (zum Beispiel MySQL Version 3.23.22). Sie finden
heraus, welche Version Sie benutzen, indem Sie
mysqladmin version eingeben.
mysqladmin findet sich im
bin-Verzeichnis unterhalb Ihres
MySQL-Installationsverzeichnisses.
Hersteller und Modell der Maschine, auf der Sie arbeiten.
Name und Version des Betriebssystems. Bei den meisten
Betriebssystemen läßt sich diese Information
herausfinden, indem man das Unix-Kommando uname
-a ausführt.
Manchmal ist die Größe des Arbeitsspeichers (real und virtuell) relevant. Im Zweifelsfall schließen Sie diese Werte ein.
Wenn Sie eine Quelldistribution von MySQL benutzen, werden Name und Versionsnummer des Compilers benötigt. Wenn Sie eine Binärdistribution haben, geben Sie den Namen der Distribution an.
Wenn das Problem während der Kompilation auftritt, schließen Sie die exakte Fehlermeldung (bzw. -meldungen) ein und zusätzlich ein paar Zeilen des Kontextes um den problembehafteten Code herum in der Datei, wo der Fehler auftrat.
Falls mysqld abstürzt, sollten Sie
auch die Anfrage (Query) mitteilen, die
mysqld zum Absturz brachte. Gewöhnlich
können Sie das herausfinden, indem Sie
mysqld mit angeschaltetem Logging
laufen lassen. See Abschnitt D.1.5, „Log-Dateien benutzen, um Gründe für Fehler in mysqld zu finden“.
Falls irgend eine Datenbanktabelle mit dem Problem zu tun
hat, schließen Sie die Ausgabe von mysqldump
--no-data db_name tbl_name1 tbl_name2 ... ein.
Das ist sehr leicht zu bewerkstelligen und eine sehr
hilfreiche Möglichkeit, Informationen über jegliche
Tabelle in einer Datenbank zu erhalten, die uns hilft,
eine Situation herzustellen, die mit derjenigen
übereinstimmt, die Sie haben.
Bei Bugs, die sich auf Geschwindigkeitsprobleme beziehen,
oder bei Problemen mit
SELECT-Statements, sollten Sie immer
die Ausgabe von EXPLAIN SELECT ...
einschließen, und zumindest die Anzahl der Zeilen, die
das SELECT-Statement produziert. Je
mehr Informationen Sie uns über Ihre Situation geben,
desto wahrscheinlicher ist es, dass Ihnen jemand helfen
kann! Das folgende Beispiel ist ein sehr gutes Beispiel
eines Bug-Berichts (es sollte natürlich mit dem
mysqlbug-Skript berichtet werden):
Beispiel unter Benutzung des
mysql-Kommandozeilen-Werkzeugs (achten
Sie auf die Benutzung des
\G-Statement-Begrenzers für
Statements, deren Ausgabebreite ansonsten die von
80-Zeilen-Ausgabegeräten überschreiten würde):
mysql>SHOW VARIABLES;mysql>SHOW COLUMNS FROM ...\G<Ausgabe von SHOW COLUMNS> mysql>EXPLAIN SELECT ...\G<Ausgabe von EXPLAIN> mysql>FLUSH STATUS;mysql>SELECT ...;<Eine Kurzfassung der Ausgabe von SELECT, inclusive der Zeit, die die Anfrage benötigte> mysql>SHOW STATUS;<Ausgabe von SHOW STATUS>
Wenn ein Problem auftritt, während
mysqld läuft, legen Sie
nach Möglichkeit ein Eingabeskript bei, das die Anomalie
reproduziert. Dieses Skript sollte alle notwendigen
Quelltextdateien beinhalten. Je exakter das Skript Ihre
Situation reproduzieren kann, desto besser. Wenn Sie einen
wiederholbaren Testfall erstellen können, sollten Sie ihn
an <bugs@lists.mysql.com> schicken, damit er
mit hoher Priorität behandelt wird!
Falls Sie kein Skript zur Verfügung stellen können,
sollten Sie zumindest die Ausgaben von mysqladmin
variables extended-status processlist in Ihrer
Mail mitschicken, um einige Informationen darüber zu
geben, wie Ihr System arbeitet!
Falls Sie keinen Testfall mit ein paar Zeilen produzieren
können oder falls Ihre Tabelle zu Groß ist, um an die
Mailing-Liste geschickt zu werden (mehr als 10 Zeilen),
sollten Sie mit mysqldump einen Dump
Ihrer Tabellen machen und eine
README-Datei erzeugen, die Ihr
Problem beschreibt.
Erzeugen Sie ein komprimiertes Archiv Ihrer Dateien, indem
Sie tar und gzip
oder zip benutzen, und benutzen Sie
ftp, um das Archiv nach
ftp://Support.mysql.com/pub/mysql/secret/
zu transferieren. Schicken Sie danach eine kurze
Beschreibung des Probleme an
<bugs@lists.mysql.com>.
Wenn Sie glauben, dass MySQL auf eine Anfrage hin merkwürdige Ergebnisse liefert, fügen Sie nicht nur das Ergebnis bei, sondern auch, wie das Ergebnis Ihrer Meinung nach aussehen sollte, sowie eine Erklärung, wie Sie zu dieser Meinung gelangt sind.
Wenn Sie ein Beispiel Ihres Problems schildern, ist es
besser, die Variablen-, Tabellen- etc. Namen zu verwenden,
die in Ihrer aktuellen Situation existieren, anstatt sich
neue Namen auszudenken. Das Problem könnte nämlich etwas
mit dem Namen der Variablen oder Tabelle zu tun haben!
Diese Fälle sind zwar selten, aber hier sollte man lieber
auf Nummer sicher gehen. Letztlich sollte es für Sie auch
leichter sein, ein Beispiel zur Verfügung zu stellen, das
Ihre tatsächliche Situation schildert, und es ist in
jedem Fall besser für uns. Falls Sie mit Daten arbeiten,
die Sie keinen anderen zeigen wollen, können Sie
ftp benutzen, um die Daten nach
ftp://Support.mysql.com/pub/mysql/secret/
zu transferieren. Falls die Daten streng geheim sind und
Sie sie nicht einmal uns zeigen wollen, legen Sie bitte
ein Beispiel mit anderen Namen an, betrachten Sie dies
aber bitte als allerletzte Möglichkeit.
Fügen Sie alle Optionen ein, die den relevanten
Programmen übergeben wurden, falls möglich. Geben Sie
zum Beispiel die Optionen an, die Sie benutzt haben, als
Sie den mysqld-Daemon gestartet haben,
und die Sie für Client-Programme wie
mysql benutzen, sowie diejenigen, die
Sie für die Konfiguration des
configure-Skripts nehmen, denn diesen
sind oft der Schlüssel für Antworten und deshalb
äußerst relevant! Es ist immer eine gute Idee, sie in
jedem Fall anzugeben! Wenn Sie Module wie Perl oder PHP
benutzen, fügen Sie bitte die Versionszahl von diesen mit
ein.
Wenn sich Ihre Frage auf das Berechtigungssystem
(Zugriffsberechtigungen auf den Datenbank-Server) bezieht,
fügen Sie bitte die Ausgabe von
mysqlaccess, die Ausgabe von
mysqladmin reload und alle
Fehlermeldungen, die Sie erhalten, wenn Sie versuchen,
sich zu verbinden, bei! Wenn Sie Ihre
Zugriffsberechtigungen testen, sollten Sie zunächst
mysqlaccess ausführen. Führen Sie
danach mysqladmin reload version aus
und versuchen Sie dann, sich mit dem Programm zu
verbinden, das Probleme macht.
mysqlaccess liegt im
bin-Verzeichnis unter Ihrem
MySQL-Installationsverzeichnis.
MySQL-Installationsverzeichnis.
Wenn Sie einen Patch für ein Bug haben, ist das gut, aber nehmen Sie bitte nicht an, dass der Patch alles ist, was wir brauchen. Gehen Sie auch nicht davon aus, dass wir den Patch benutzen werden, wenn Sie nicht auch einige notwendige Informationen mitschicken, zum Beispiel Testfälle, die den Bug zeigen, der durch Ihren Patch behoben wird. Möglicherweise finden wir Probleme, die Ihr Patch verursacht, oder wir verstehen ihn überhaupt nicht. Wenn das der Fall ist, können wir ihn nicht benutzen.
Wenn wir nicht genau feststellen können, wofür der Patch gedacht ist, werden wir ihn nicht benutzen. In diesen Fällen werden uns Testfälle weiter helfen. Zeigen Sie darin auf, dass der Patch all die Situationen bewältigt, die eintreten können. Falls wir einen Grenzfall finden (sogar, wenn es ein seltener ist), bei dem der Patch nicht funktioniert, ist er vielleicht nutzlos.
Vermutungen, worin der Bug besteht, warum er auftritt oder wovon er abhängt, sind meist falsch. Selbst das MySQL-Team kann solche Dinge nicht erraten, sondern muss einen Debugger benutzen, um den wahren Grund des Bugs feststellen zu können.
Geben Sie in Ihrer Mail zu erkennen, dass Sie das Referenzhandbuch gelesen und die Mail-Archive durchgesehen haben, damit andere wissen, dass Sie versucht haben, das Problem selbst zu lösen.
Wenn Sie einen parse error erhalten,
überprüfen Sie bitte genau Ihre Syntax! Wenn Sie nichts
Falsches darin finden können, ist es sehr wahrscheinlich,
dass Ihre aktuelle Version von MySQL die Anfrage, die Sie
formuliert haben, nicht unterstützt. Wenn Sie die
aktuelle Version benutzen und das Handbuch unter
http://www.mysql.com/documentation/manual.php
die Syntax, die Sie benutzen, nicht beschreibt,
unterstützt MySQL Ihre Anfrage nicht. In diesem Fall
bleibt Ihnen nur, die Syntax entweder selbst zu
implementieren oder per E-Mail an
<mysql-licensing@mysql.com> nach einem
Angebot für die Implementation anzufragen!
Wenn das Handbuch die Syntax, die Sie benutzen, beschreibt, Sie aber eine ältere Version von MySQL benutzen, sollten Sie in der MySQL-Änderungsgeschichte (Change History) nachsehen, wann die Syntax implementiert wurde. In diesem Fall haben Sie die Möglichkeit, ein Upgrade auf eine neuere Version von MySQL vorzunehmen. See Anhang C, MySQL-Änderungsverlauf (Change History).
Wenn Sie ein Problem in der Art haben, dass Ihre Daten
anscheinend beschädigt sind oder Sie Fehlermeldungen
bekommen, wenn Sie auf eine bestimmte Tabelle zugreifen,
sollten Sie zunächst Ihre Tabellen überprüfen und
anschließend reparieren, indem Sie
myisamchk oder CHECK
TABLE und REPAIR TABLE
benutzen. See
Kapitel 5, MySQL-Datenbankadministration.
Wenn Sie oft beschädigte Tabellen erhalten, sollten Sie
versuchen herauszufinden, wann und warum das geschieht! In
diesem Fall kann die
mysql-data-directory/'hostname'.err-Datei
einige Informationen darüber enthalten, was geschehen
ist. See Abschnitt 5.9.1, „Die Fehler-Log-Datei“. Bitte fügen Sie
jede relevante Information aus dieser Datei in Ihren
Bug-Bericht ein! Normalerweise sollte
mysqld
NIE eine Tabelle
zerstören, ausser wenn der Server mitten während eines
Updates gekillt wurde! Wenn Sie den Grund für den Absturz
von mysqld herausfinden können, ist es
sehr viel einfacher für uns, Ihnen eine Lösung des
Problems an die Hand zu geben! See
Abschnitt A.1, „Wie man feststellt, was Probleme verursacht“.
Falls möglich, sollten Sie die aktuellste Version von MySQL herunter laden, installieren und überprüfen, ob das Ihr Problem löst. Alle Versionen von MySQL werden gründlich getestet und sollten ohne Probleme funktionieren! Wir halten uns daran, alles so abwärtskompatibel wie möglich zu machen. Daher sollte es Ihnen möglich sein, innerhalb von Minuten die MySQL-Version auszutauschen! See Abschnitt 3.2.3, „Welche MySQL-Version Sie benutzen sollten“.
Wenn Sie ein Support-Kunde sind, schicken Sie bitte den
Bug-Bericht an <mysql-Support@mysql.com>, damit
dieser eine höhere Priorität in der Bearbeitung erfährt.
Schicken Sie ihn gleichzeitig an die entsprechende
Mailing-Liste, um zu sehen, ob schon jemand anderes das selbe
Problem hatte (und vielleicht gelöst hat).
Informationen zu Bug-Berichten siehe MyODBC und Abschnitt 9.3.4, „Wie Sie Probleme mit MyODBC berichten“.
Lösungen für häufig auftretende Probleme siehe See Anhang A, Probleme und häufige Fehler.
Wenn Ihnen Antworten individuell zugesandt werden und nicht an die Mailing-Liste, wird es als gute Etikette betrachtet, die Antworten zusammenzufassen und die Zusammenfassung an die Mailing-Liste zu schicken, damit andere von den Antworten profitieren können, die Ihnen geholfen haben, Ihr Problem zu lösen!
Wenn Sie davon ausgehen, dass Ihre Antwort auf breites Interesse stößt, sollten Sie an die Mailing-Liste posten, statt direkt der Person zu antworten, die die Frage stellte. Versuchen Sie, Ihre Antwort so allgemein zu halten, dass auch andere als der ursprünglich Fragende von Ihrer Antwort profitieren können. Wenn Sie an die Liste posten, stellen Sie bitte sicher, dass Ihre Antwort kein Duplikat einer vorhergehenden Antwort ist.
Versuchen Sie, den wesentlichen Teil der Frage in Ihrer Antwort zusammenzufassen. Fühlen Sie sich nicht verpflichtet, die gesamte ursprüngliche Nachricht zu zitieren.
Bitte schicken Sie Ihre Mailnachrichten nicht im HTML-Format! Viele Benutzer lesen Nachrichten mit nicht HTML-fähigen Anwendungen!
Dieser Abschnitt beschreibt, wie sich MySQL zum ANSI SQL-Standard verhält. MySQL hat viele Erweiterungen zum ANSI SQL-Standard, und hier steht, welche das sind und wie man sie benutzt. Hier finden Sie auch Informationen über Funktionalität, die MySQL fehlt, und wie man mit diesen Unterschieden umgeht.
Entry-Level-SQL92. ODBC-Levels 0-2.
Wir beabsichtigen ANSI SQL99 vollständig zu unterstützen. Dies wollen wir jedoch keinesfalls auf Kosten von Geschwindigkeit oder Codequalität erreichen.
Wenn Sie mysqld mit der
--ansi-Option starten, ändert sich folgendes
Verhalten von MySQL:
|| ist Zeichenketten-Verkettung
(Konkatenation) anstelle von OR.
Sie können eine beliebige Anzahl von Leerzeichen zwischen
Funktionnamen und ‘(’
eingeben. Das führt zwangsläufig dazu, dass alle
Funktionsnamen als reservierte Wörter behandelt werden.
‘"’ ist dann ein
Quotierungsbezeichner (wie das MySQL-
‘`’-Anführungszeichen) und
kein Zeichen, dass einen String einschließt.
REAL wird zu einem Synonym für
FLOAT anstelle eines Synonyms für
DOUBLE.
Der Standard-Isolationslevel für Transaktionen ist
SERIALIZABLE. See
Abschnitt 7.7.3, „SET TRANSACTION-Syntax“.
Das ist dasselbe, als würde man
--sql-mode=REAL_AS_FLOAT,PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE,SERIALIZE,ONLY_FULL_GROUP_BY
benutzen.
MySQL beinhaltet einige Erweiterungen, die Sie in anderen
SQL-Datenbanken wahrscheinlich nicht finden werden. Passen Sie
auf, wenn Sie diese benutzen, denn Ihr Code ist dann nicht mehr
kompatibel mit anderen SQL-Servern. In einigen Fällen können
Sie Code schreiben, der MySQL-Erweiterungen enthält und dennoch
portabel ist, indem Sie Kommentare in der Form /*! ...
*/ benutzen. In diesem Fall wird MySQL den Code
innerhalb des Kommentars parsen und ausführen wie jedes andere
MySQL-Statement, aber andere SQL-Server werden die Erweiterungen
ignorieren. Zum Beispiel:
SELECT /*! STRAIGHT_JOIN */ col_name FROM tabelle1, tabelle2 WHERE ...
Wenn Sie hinter '!' die Versionsnummer
angeben, wird die Syntax nur ausgeführt, wenn die MySQL-Version
gleich oder neuer als die benutzte Versionsnummer ist:
CREATE /*!32302 TEMPORARY */ TABLE (a int);
Je höher bedeutet, wenn Sie Version 3.23.02 oder neuer haben,
wird MySQL das TEMPORARY-Schlüsselwort
benutzen.
MySQL-Erweiterungen sind:
Die Feldtypen MEDIUMINT,
SET, ENUM und die
unterschiedlichen BLOB- und
TEXT-Typen.
Die Feldattribute AUTO_INCREMENT,
BINARY, NULL,
UNSIGNED und ZEROFILL.
Alle Zeichenkettenvergleiche achten vorgabemäßig nicht auf
Groß-/Kleinschreibung, wobei die Sortierreihenfolge vom
aktuell verwendeten Zeichensatz abhängig ist (ISO-8859-1
Latin1 als Vorgabe). Wenn Sie das nicht wollen, sollten Sie
Ihre Spalten mit dem BINARY-Attribut
deklarieren oder den BINARY-Cast
benutzen, der dafür sorgt, dass Vergleiche mit der
ASCII-Sortierung durchgeführt werden, die der
MySQL-Server-Host benutzt.
MySQL legt jede Datenbank als Verzeichnis unterhalb des MySQL-data- Verzeichnisses an und Tabellen innerhalb einer Datenbank als Dateien in dem Datenbank-Verzeichnis.
Das hat ein paar Auswirkungen:
Bei Datenbanknamen und Tabellennamen wird auf Unterschiede in der Groß-/Kleinschreibung geachtet, wenn das Betriebssystem auf Groß-/Kleinschreibung achtet (wie auf den meisten Unix-Systemen). See Abschnitt A.5.1, „Groß-/Kleinschreibung beim Suchen“.
Datenbank-, Tabellen-, Index-, Spalten- oder Alias-Namen dürfen mit einer Ziffer beginnen (aber nicht ausschließlich aus Ziffern bestehen).
Sie können Standard-Kommandos des Betriebssystems
benutzen, um Tabellen zu sichern (Datensicherung),
umzubenennen, zu verschieben, zu löschen und zu
kopieren. Um zum Beispiel eine Tabelle umzubennen,
benennen Sie die Dateien .MYD,
.MYI und .frm
um, die der Tabelle entsprechen.
In SQL-Statements können Sie Tabellen aus verschiedenen
Datenbanken mit der
db_name.tbl_name-Syntax ansprechen.
Einige SQL-Syntax stellen dieselbe Funktionalität zur
Verfügung, nennen dies aber User space.
MySQL unterstützt keine Tablespaces wie in folgendem
Beispiel: create tabelle ralph.meine_tabelle...IN
mein_tablespace.
LIKE ist für numerische Spalten erlaubt.
Die Benutzung von INTO OUTFILE und
STRAIGHT_JOIN in einem
SELECT-Statement. See
Abschnitt 7.4.1, „SELECT-Syntax“.
Die Option SQL_SMALL_RESULT in einem
SELECT-Statement.
EXPLAIN SELECT, um eine Beschreibung zu
erhalten, wie Tabellen verknüpft werden (Join).
Die Benutzung von Index-Namen, Indexen auf ein Prefix eines
Feldes, und die Benutzung von INDEX oder
KEY in einem CREATE
TABLE- Statement. See
Abschnitt 7.5.3, „CREATE TABLE-Syntax“.
Die Benutzung von TEMPORARY oder
IF NOT EXISTS mit CREATE
TABLE.
Die Benutzung von COUNT(DISTINCT list),
wobei 'list' mehr als ein Element ist.
Die Benutzung von CHANGE spalten_name,
DROP spalten_name, oder DROP
INDEX, IGNORE oder
RENAME in einem ALTER
TABLE-Statement. See
Abschnitt 7.5.4, „ALTER TABLE-Syntax“.
Die Benutzung von RENAME TABLE. See
Abschnitt 7.5.5, „RENAME TABLE-Syntax“.
Die Benutzung mehrfacher ADD-,
ALTER-, DROP-, oder
CHANGE-Klauseln in einem ALTER
TABLE Statement.
Die Benutzung von DROP TABLE mit the
keywords IF EXISTS.
Sie können mehrere Tabellen löschen mit einem einzigen
DROP TABLE-Statement.
Die LIMIT-Klausel des
DELETE-Statements.
Die DELAYED-Klausel der
INSERT- und REPLACE-
Statements.
Die LOW_PRIORITY-Klausel der
INSERT-, REPLACE-,
DELETE- und
UPDATE-Statements.
Die Benutzung von LOAD DATA INFILE. In
vielen Fällen ist diese Syntax kompatibel mit Oracles
LOAD DATA INFILE. See
Abschnitt 7.4.9, „LOAD DATA INFILE-Syntax“.
Die ANALYZE TABLE-, CHECK
TABLE-, OPTIMIZE TABLE- und
REPAIR TABLE-Statements.
Das SHOW-Statement. See
Abschnitt 5.5.5, „SHOW-Syntax“.
Zeichenketten dürfen sowohl durch
‘"’ als auch durch
‘'’ eingeschlossen werden,
nicht nur durch ‘'’.
Die Benutzung des
Escape(‘\’)Zeichens.
Das SET OPTION-Statement. See
Abschnitt 6.5.6, „SET-Syntax“.
Sie müssen nicht alle ausgewählten Spalten im
GROUP BY-Teil nennen. Hierdurch ergibt
sich eine bessere Performance für einige sehr spezifische,
aber recht gewöhnliche Anfragen.
Man kann ASC und DESC
bei GROUP BY spezifizieren.
Um es Benutzern leichter zu machen, die von anderen SQL-Umgebungen kommen, unterstützt MySQL Aliase für viele Funktionen. Zum Beispiel unterstützen alle Zeichenketten-Funktionen sowohl die ANSI-SQL-Syntax als auch die ODBC-Syntax.
MySQL kennt die Operatoren || und
&&, die logisches Oder und
logisches Und bedeuten, wie in der Programmiersprache C. In
MySQL sind || und OR
Synonyme, wie auch && und
AND. Aufgrund dieser freundlichen Syntax
unterstützt MySQL nicht den
ANSI-SQL-||-Operator für
Zeichenketten-Verkettung (Konkatenation); benutzen Sie statt
dessen CONCAT(). Weil
CONCAT() eine beliebige Anzahl von
Argumenten entgegennimmt, ist es leicht, die Benutzung des
||-Operators zu MySQL zu konvertieren.
CREATE DATABASE oder DROP
DATABASE. See Abschnitt 7.5.1, „CREATE DATABASE-Syntax“.
Der %-Operator ist ein Synonym für
MOD(). Das heißt N %
M ist äquivalent zu MOD(N,M).
% wird für C-Programmierer und für
Kompatibilität mit PostgreSQL unterstützt.
Die =-, <>-,
<=-, <-,
>=-, >-,
<<-, >>-,
<=>-, AND-,
OR- oder
LIKE-Operatoren können in
Spaltenvergleichen links von FROM in
SELECT Statements benutzt werden.
Beispiel:
mysql> SELECT spalte1=1 AND spalte2=2 FROM tabelle_name;
Die LAST_INSERT_ID()-Funktion. See
Abschnitt 9.4.3.30, „mysql_insert_id()“.
Die REGEXP- und NOT
REGEXP-Operatoren für erweiterte reguläre
Ausdrücke.
CONCAT() oder CHAR()
mit einem Argument oder mehr als zwei Argumenten. (In MySQL
können diese Funktionen jede beliebige Anzahl von
Argumenten entgegennehmen.)
Die Funktionen BIT_COUNT(),
CASE, ELT(),
FROM_DAYS(), FORMAT(),
IF(), PASSWORD(),
ENCRYPT(), md5(),
ENCODE(), DECODE(),
PERIOD_ADD(),
PERIOD_DIFF(),
TO_DAYS() oder
WEEKDAY().
Die Benutzung von TRIM(), um Teile von
Zeichenketten zu entfernen. ANSI SQL unterstützt nur die
Entfernung einzelner Zeichen.
Die GROUP BY-Funktionen
STD(), BIT_OR() und
BIT_AND().
Die Benutzung von REPLACE anstelle von
DELETE + INSERT. See
Abschnitt 7.4.8, „REPLACE-Syntax“.
Das FLUSH flush_option-Statement.
Die Möglichkeit, Variablen in einem Statement mit
:= zu setzen:
SELECT @a:=SUM(total),@b=COUNT(*),@a/@b AS avg FROM test_tabelle; SELECT @t1:=(@t2:=1)+@t3:=4,@t1,@t2,@t3;
Wir versuchen möglichst, dass MySQL dem ANSI-SQL-Standard und dem ODBC-SQL-Standard folgt, aber in einigen Fällen macht MySQL Dinge auf andere Weise:
-- ist nur dann ein Kommentar, wenn darauf
Whitespace folgt. See Abschnitt 2.7.4.8, „'--' als Beginn eines Kommentars“.
Bei VARCHAR-Spalten werden Leerzeichen am
Ende entfernt, wenn der Wert gespeichert wird. See
Abschnitt 2.7.5, „Bekannte Fehler und Design-Unzulänglichkeiten in MySQL“.
In einigen Fällen ändern sich
CHAR-Spalten automatisch (silent) in
VARCHAR-Spalten. See
Abschnitt 7.5.3.1, „Stille Spaltentyp-Änderungen“.
Zugriffsrechte für eine Tabelle werden nicht automatisch
widerrufen, wenn Sie eine Tabelle löschen. Sie müssen
explizit ein REVOKE-Statement absetzen,
um die Zugriffsrechte für eine Tabelle zu widerrufen. See
Abschnitt 5.3.1, „GRANT- und REVOKE-Syntax“.
NULL AND FALSE werden zu
NULL ausgewertet und nicht zu
FALSE. Der Grund hierfür liegt darin,
dass wir meinen, dass es keine gute Idee ist, eine Menge von
Sonderkonditionen für diesen Fall auswerten zu müssen.
MySQL unterstützt momentan nur Sub-Selects der Form
INSERT ... SELECT ... und REPLACE
... SELECT .... In anderen Zusammenhängen können
Sie allerdings die Funktion IN() benutzen.
In vielen Fällen können Sie Ihre Anfragen ohne Sub-Selects schreiben:
SELECT * FROM tabelle1 WHERE id IN (SELECT id FROM tabelle2);
Das kann wie folgt umgeschrieben werden:
SELECT tabelle1.* FROM tabelle1,tabelle2 WHERE tabelle1.id=tabelle2.id;
Die Anfragen:
SELECT * FROM tabelle1 WHERE id NOT IN (SELECT id FROM tabelle2); SELECT * FROM tabelle1 WHERE NOT EXISTS (SELECT id FROM tabelle2 where tabelle1.id=tabelle2.id);
Können wie folgt umgeschrieben werden:
SELECT tabelle1.* FROM tabelle1 LEFT JOIN tabelle2 ON tabelle1.id=tabelle2.id where tabelle2.id IS NULL
Für kompliziertere Unteranfragen (Subqueries) können Sie oft
temporäre Tabelle anlegen, die die Unteranfrage enthalten. In
einigen Fällen wird diese Option allerdings nicht
funktionieren. Am häufigsten treten diese Fälle mit
DELETE-Statements auf, wofür Standard-SQL
keine Verknüpfungen (Joins) unterstützt. Für solche
Situationen sind zwei Optionen verfügbar, solange MySQL noch
keine Unteranfragen unterstützt.
Die erste Option besteht darin, eine prozedurale
Programmiersprache (wie PHP oder Perl) zu benutzen, um eine
SELECT-Anfrage zu erhalten, die die
Primärschlüssel enthält, die benötigt werden, um die
entsprechenden Datensätze zu löschen, und dann diese Werte
zu benutzen, um das DELETE-Statement zu
formulieren (DELETE FROM ... WHERE ... IN (key1,
key2, ...)).
Die zweite Option besteht darin, interaktives SQL zu benutzen,
um automatisch eine Reihe von
DELETE-Statements zu formulieren, indem die
MySQL-Erweiterung CONCAT() benutzt wird
(anstelle des Standard-Operators ||).
Beispiel:
SELECT CONCAT('DELETE FROM tabelle1 WHERE pkid = ', tabelle1.pkid, ';')
FROM tabelle1, tabelle2
WHERE tabelle1.spalte1 = tabelle2.spalte2;
Sie können diese Anfrage in eine Skriptdatei schreiben und
deren Eingabe an den Kommandozeilen-Interpreter
mysql leiten und von dort die Ausgabe
zurück an eine zweite Instanz des Interpreters:
prompt> mysql --skip-column-names meine_db < mein_skript.sql | mysql meine_db
MySQL 4.0 unterstützt das Löschen aus mehreren Tabellen (multi-table deletes), was benutzt werden kann, um effizient Zeilen zu löschen, basierend auf den Informationen aus einer Tabelle oder sogar aus mehreren Tabellen zur gleichen Zeit.
MySQL unterstützt noch nicht die Oracle-SQL-Erweiterung
SELECT ... INTO TABLE .... MySQL
unterstützt statt dessen die ANSI-SQL-Syntax INSERT
INTO ... SELECT ..., die im Prinzip dasselbe ist.
See Abschnitt 7.4.3.1, „INSERT ... SELECT-Syntax“.
INSERT INTO tabelle_temp2 (fldID) SELECT tabelle_temp1.fldOrder_ID FROM tabelle_temp1 WHERE tabelle_temp1.fldOrder_ID > 100;
Alternativ können Sie SELECT INTO
OUTFILE... oder CREATE TABLE ...
SELECT benutzen, um Ihre Probleme zu lösen.
Weil MySQL heutzutage Transaktionen unterstützt, gelten die
folgenden Erörterungen nur, wenn Sie nur Tabellentypen
benutzen, die nicht transaktionssicher sind. See
Abschnitt 7.7.1, „BEGIN/COMMIT/ROLLBACK-Syntax“.
Oft wird von neugierigen oder kritischen Leuten gefragt: ``Warum ist MySQL keine transaktionale Datenbank?'' oder ``Warum unterstützt MySQL keine Transaktionen?''
MySQL hat sich bewusst entschieden, andere Paradigmen für die Datenintegrität zu unterstützen: ``atomische Operationen.'' Es entspricht unserer Denkweise und unserer Erfahrung, dass atomische Operationen gleiche oder bessere Integrität bei wesentlich besserer Performance gewährleisten. Nichtsdestotrotz schätzen und verstehen wir das transaktionale Datenbank-Paradigma und planen, im Verlauf der nächsten Releases transaktionssichere Tabellen einzuführen, auf der Basis der Transaktionssicherheit pro einzelner Tabelle. Wir werden unseren Benutzern die Entscheidung überlassen, ob Sie in ihren Applikationen den Geschwindigkeitsvorteil atomischer Operationen benötigen oder die transaktionalen Features.
Wie benutzt man die Features von MySQL, um rigorose Integrität beizubehalten, und wie sind diese Features im Vergleich mit dem transaktionalen Paradigma zu bewerten?
Zunächst ist es nach dem transaktionalen Paradigma bequemer, mit Transaktionen zu arbeiten, wenn Ihre Applikationen auf eine Weise geschrieben sind, dass sie in kritischen Situationen ``rollback'' anstelle von ``commit'' aufrufen. Darüber hinaus stellen Transaktionen sicher, dass unbeendete Updates oder zerstörende Aktivitäten nicht an die Datenbank abgesetzt werden; der Server hat die Gelegenheit, ein automatisches Rollback durchzuführen, wodurch Ihre Datenbank gerettet wird.
In fast allen Fällen erlaubt Ihnen MySQL, potentiellen Problemen vorzubauen, indem einfache Überprüfungen eingebaut und einfache Skripte laufen gelassen werden, die die Datenbanken auf Inkonsistenzen prüfen und automatisch reparieren oder Warnmeldungen ausgeben, wenn so etwas passiert. Beachten Sie auch, dass allein durch die Benutzung der MySQL-Logdatei oder durch das Hinzufügen einer speziellen Logdatei Tabellen perfekt repariert werden können, ohne dass ein Verlust an Datenintegrität eintritt.
Darüber hinaus können fatale transaktionale Updates so
umgeschrieben werden, dass sie atomisch sind. In der Tat gehen
wir so weit zu sagen, dass alle Integritätsprobleme, die
Transaktionen lösen, mit LOCK TABLES oder
atomischen Update durchgeführt werden können, was
sicherstellt, dass Sie nie einen automatischen Abbruch von der
Datenbank bekommen, was ein gewöhnliches Problem
transaktionaler Datenbanken darstellt.
Nicht einmal Transaktionen können jeden Verlust verhindern, wenn der Server abstürzt. In solchen Fällen können sogar transaktionale Systeme Daten verlieren. Der Unterschied zwischen unterschiedlichen Systemen besteht einzig darin, wie kurz die Zeitverzögerung ist, in der Daten verloren gehen könnten. Kein System ist 100%-ig sicher, sondern lediglich ``sicher genug''. Selbst von Oracle, ansonsten als das sicherste aller transaktionalen Datenbanken berühmt, wird berichtet, dass es manchmal in solchen Situationen Daten verliert.
Um mit MySQL auf der sicheren Seite zu sein, brauchen Sie lediglich Datensicherungen und angeschaltetes Update-Logging. Damit können Sie in jeder denkbaren Situation genau wie mit jeder beliebigen transaktionalen Datenbank Daten wiederherstellen. Natürlich ist es immer eine gute Idee, Datensicherungen zu haben, unabhängig von der verwendeten Datenbank.
Das transaktionale Paradigma hat seine Vor- und Nachteile.
Viele Benutzer und Applikationsentwickler verlassen sich auf
die Einfachheit, mit der sie um Probleme herum Code schreiben
können, dort wo anscheinend ein Abbruch erfolgt ist, oder wo
es notwendig ist, haben sie womöglich ein bisschen mehr
Arbeit mit MySQL, weil sie anders denken oder mehr schreiben
müssen. Wenn Ihnen atomische Operationen neu sind oder Sie
vertrauter mit Transaktionen sind (oder Sie sich damit besser
fühlen), kommen Sie nicht gleich zur Schlussfolgerung, dass
sich MySQL nicht mit diesen Überlegungen beschäftigt hat.
Zuverlässigkeit und Integrität stehen für uns absolut im
Vordergrund. Aktuelle Schätzungen gehen davon aus, dass zur
Zeit mehr als eine Million mysqld-Server
laufen, von denen viele in Produktionsumgebungen eingesetzt
werden. Wir hören sehr, sehr selten von Benutzern, die
irgendwelche Daten verloren haben, und in fast allen Fällen
sind Benutzerfehler im Spiel. Das ist unserer Meinung nach der
beste Beweis für die Stabilität und Zuverlässigkeit von
MySQL.
Im übrigen lassen die aktuellen Features von MySQL
Zuverlässigkeit und Integrität auf Transaktionsebene oder
besser zu, wenn in bestimmten Situationen Integrität von
höchster Wichtigkeit ist. Wenn Sie Tabellen mit LOCK
TABLES sperren, werden alle Updates angehalten, bis
jegliche Integritätsprüfungen durchgeführt sind. Wenn Sie
nur eine Lesesperre (Read Lock) machen (im Gegensatz zu einer
Schreibsperre - Write Lock), werden Lese- und
Einfügeoperationen noch zugelassen. Die neu eingefügten
Datensätze können von nicht Clients gesehen werden, die eine
READ-Sperre haben, bis sie ihre Lesesperre
aufheben. Mit INSERT DELAYED können Sie
Einfügeoperationen in eine lokale Warteschlange (Local Queue)
stellen, solange, bis die Sperren aufgehoben sind, ohne dass
der Client warten muss, bis die Einfügeoperationen
abgeschlossen sind. See Abschnitt 7.4.4, „INSERT DELAYED-Syntax“.
``Atomisch'', so wie wir es meinen, ist nichts Magisches. Es bedeutet nur, dass Sie sicher sein können, dass kein anderer Benutzer mit irgendeinem laufenden Update in Konflikt kommen kann, und dass es nie ein automatisches Rollback geben kann (was bei transaktionsbasierenden Systemen vorkommen kann, wenn Sie nicht sehr vorsichtig sind). MySQL garantiert auch, dass es keine schmutzigen Lesezugriffe (Dirty Reads) gibt. Sie finden einige Beispiele, wie man atomische Updates schreibt, im Abschnitt über Commits und Rollbacks.
Wir haben reichlich über Integrität und Performance nachgedacht und glauben, dass unser atomisches Paradigma sowohl Zuverlässigkeit als auch extrem hohe Performance gewährleistet, und zwar drei- bis fünfmal schneller, als es die schnellste und optimal eingestellte transaktionale Datenbank schafft. Wir haben Transaktionen nicht deshalb heraus gelassen, weil sie schwer zu machen sind. Der Hauptgrund für die Entscheidung für atomische Operationen gegen Transaktionen liegt darin, dass wir dadurch viele Geschwindigkeitsoptimierungen machen konnten, die auf andere Art nicht möglich gewesen wären.
Viele unserer Benutzer, für die Geschwindigkeit das
Wichtigste ist, haben keinerlei Bedenken hinsichtlich
Transaktionen. Für sie sind Transaktionen kein Thema.
Diejenigen Benutzer, die Sorgen mit Transaktionen haben oder
sich darüber wundern, dass MySQL diese nicht unterstützt,
gibt es eine ``MySQL-Art'', die wir weiter oben beschrieben
haben. Denjenigen, denen Sicherheit wichtiger als
Geschwindigkeit ist, empfehlen wir die Benutzung von
BDB- oder
InnoDB-Tabellen für alle kritischen Daten.
See Kapitel 8, MySQL-Tabellentypen.
Ein letzter Hinweis: Wir arbeiten zur Zeit an einem sicheren Replikationsschema, vom dem wir glauben, dass es besser als jedes kommerzielle Replikationssystem ist, das wir kennen. Dieses System wird mit dem atomischen, nicht-transaktionalen Paradigma mit höchster Zuverlässigkeit laufen. Bleiben Sie dran!
Eine gespeicherte Prozedur ist ein Satz von SQL-Kommandos, die kompiliert und auf dem Server gespeichert werden können. Wenn dies einmal geschehen ist, müssen Clients nicht mehr die gesamte Anfrage absetzen, sondern können sich auf die gespeicherte Prozedur beziehen. Hiermit wird bessere Performance erreicht, den die Anfrage muss nur einmal geparst werden, und es muss weniger Information zwischen Client und Server ausgetauscht werden. Man kann sogar die konzeptionelle Ebene steigern, indem man Bibliotheken von Funktionen auf dem Server bereit hält.
Ein Trigger ist eine gespeicherte Prozedur, die aufgerufen wird, wenn ein bestimmtes Ereignis eintritt. Beispielsweise kann man eine gespeicherte Prozedur installieren, die jedes Mal ausgeführt wird, wenn ein Datensatz aus einer Transaktionstabelle gelöscht wird, und die automatisch den dazu gehörigen Kunden aus einer Kundentabelle löscht, wenn alle seine Transaktionen gelöscht wurden.
Für ein späteres Release ist geplant, dass MySQL gespeicherte Prozeduren handhaben kann, aber ohne Trigger. Trigger verlangsamen üblicherweise alles, sogar Anfragen, für die sie nicht benötigt werden.
Um festzustellen, ab wann MySQL gespeicherte Prozeduren bekommen wird, siehe auch Abschnitt 2.8, „MySQL und die Zukunft (das TODO)“.
Ab MySQL-Serverversion 3.23.44 unterstützen
InnoDB-Tabellen die Prüfung auf
Fremdschlüsselbeschränkungen wie CASCADE,
ON DELETE und ON UPDATE.
Bei anderen Tabellentypen parst der MySQL-Server die
FOREIGN KEY-Syntax in CREATE
TABLE-Befehlen lediglich, benutzt oder speichert
diese Informationen jedoch nicht.
Beachten Sie, dass Fremdschlüssel in SQL nicht dazu benutzt
werden, um Tabellen zu verknüpfen, sondern hauptsächlich, um
die referentielle Integrität zu überprüfen
(Fremdschlüssel-Restriktionen). Wenn Sie durch ein
SELECT-Statement Ergebnisse aus mehreren
Tabellen erhalten wollen, tun Sie dies, indem Sie Tabellen
verknüpfen (Join):
SELECT * FROM table1,table2 WHERE table1.id = table2.id;
See Abschnitt 7.4.1.1, „JOIN-Syntax“. See
Abschnitt 4.5.6, „Wie Fremdschlüssel (Foreign Keys) verwendet werden“.
Wenn Fremdschlüssel (FOREIGN KEYs) als
Beschränkung benutzt werden, müssen sie nicht verwendet
werden, wenn eine Applikation Zeilen in der korrekten
Reihenfolge in MyISAM-Tabellen einfügt.
Bei MyISAM-Tabellen können Sie das
Problem, dass ON DELETE... nicht
implementiert ist, dadurch umgehen, dass Sie das entsprechende
DELETE-Statement einer Applikation
hinzufügen, wenn Sie Datensätze aus einer Tabelle löschen,
die Fremdschlüssel hat. In der Praxis ist das genauso schnell
(in einigen Fällen schneller) und wesentlich portabler, als
wenn Sie Fremdschlüssel benutzen würden.
Beim MySQL-Server 4.0 können Sie das Löschen aus mehreren
Tabellen verwenden (Multi-Table Delete), um mit einem einzigen
Befehl Zeilen aus vielen Tabellen zu löschen. See
Abschnitt 7.4.6, „DELETE-Syntax“.
Die FOREIGN KEY-Syntax ohne ON
DELETE ... wird oft von ODBC-Applikationen
verwendet, um automatische WHERE-Klauseln
zu erzeugen.
Die FOREIGN KEY-Implementation wird
künftig so erweitert werden, dass die Informationen in der
Tabellendefinitionsdatei gespeichert werden und von
mysqldump und ODBC abgerufen werden
können. Für einen späteren Zeitpunkt ist vorgesehen, auch
für MyISAM-Tabellen
Fremdschlüsselbeschränkungen hinzuzufügen.
Denken Sie daran, dass Fremdschlüssel oft falsch eingesetzt werden, was zu schweren Problemen führen kann. Selbst wenn sie korrekt verwendet werden, sind sie keine Zauberlösung für das Problem der referenziellen Integrität, doch können sie solche Dinge erleichtern.
Einige Vorteile der Erzwingung von Fremdschlüsselbeschränkungen sind:
Korrekte Konzeption der Beziehungen vorausgesetzt erschweren es Fremdschlüsselbeschränkungen einem Programmierer, in eine Datenbank Inkonsistenzen einzuführen.
Kaskadierende Updates und Deletes können den Applikationscode vereinfachen.
Korrekt konzipierte Fremdschlüsselregeln erleichtern das Dokumentieren von Beziehungen zwischen Tabellen.
Nachteile:
Fehler, die beim Konzipieren von Fremdschlüsselbeziehungen leicht vorkommen, können schwerwiegende Probleme verursachen. Beispiele hierfür sind zirkuläre Regeln oder die falsche Kombination kaskadierender Deletes.
Eine korrekt geschriebene Applikation stellt bereits intern sicher, dass sie Beschränkungen zur Wahrung der referenziellen Integrität nicht verletzt, bevor sie eine Anfrage absetzt. Daher führen zusätzliche Überprüfungen auf Datenbankebene dazu, dass die Performanz einer Applikation sinkt.
Häufig kommt es auch vor, dass ein DBA eine solchermaßen komplexe Topologie von Beziehungen anlegt, dass es schwierig oder gar unmöglich wird, die einzelnen Tabellen zu sichern oder wiederherzustellen.
Die Informationen auf dieser Seite befinden sich in
Überarbeitung. Ab MySQL-Serverversion 3.23.44 unterstützen
InnoDB-Tabellen die Prüfung auf
Fremdschlüsselbeschränkungen wie CASCADE,
ON DELETE und ON UPDATE.
MySQL unterstützt noch keine Sichten. Die Implementierung von Views ist aber für Version 5.1 geplant.
Sichten sind äußerst nützlich, um Benutzern Zugang zu einem Satz von Beziehungen wie zu einer einzigen Tabelle zu gewähren (Lesezugriff). Viele SQL-Datenbanken lassen es nicht zu, dass irgend welche Zeilen in einer Sicht aktualisiert werden (Update). Statt dessen müssen die einzelnen Tabellen aktualisiert werden.
Weil MySQL meist in Applikationen und in Web-Systemen eingesetzt wird, wo der Applikationsprogrammierer volle Kontrolle über die Datenbankbenutzung hat, sehen die meisten unserer Benutzer Sichten als nicht sehr wichtig an.
In MySQL werden Sichten nicht benötigt, um den Zugriff auf Spalten zu beschränken, weil MySQL ein sehr ausgefeiltes System der Zugriffsberechtigungen hat. See Abschnitt 5.2, „Allgemeine Sicherheitsthemen und das MySQL-Zugriffsberechtigungssystem“.
Einige andere SQL-Datenbanken benutzen '--',
um Kommentare zu beginnen. MySQL benutzt
‘#’ als Anfangszeichen, wenn
auch das mysql-Kommandozeilen-Werkzeug alle
Zeilen entfernt, die mit '--' anfangen. Sie
können in MySQL auch Kommentare im C-Stil verwenden
/* Das ist ein Kommentar */. See
Abschnitt 7.1.5, „Kommentar-Syntax“.
MySQL ab Version 3.23.3 unterstützt Kommentare, die mit
'--' beginnen, allerdings nur, wenn der
Kommentarbeginn von einem Leerzeichen gefolgt wird. Der Grund
liegt darin, dass dieser degenerierte Kommentar-Stil eine
Menge Probleme mit automatisch generierten SQL-Anfragen
verursacht, die Ähnliches wie den folgenden Code benutzen, wo
automatisch der Wert einer Zahlung für
!zahlung! eingefügt wird:
UPDATE tabelle_name SET kredit=kredit-!zahlung!
Was, glauben Sie, passiert, wenn der Wert von
zahlung negativ wird?
Weil 1--1 in SQL zulässig ist, sind wir
der Meinung, dass es furchtbar ist, dass '--'
den Anfang eines Kommentars bedeutet.
In MySQL ab Version 3.23 können Sie allerdings folgendes
benutzen: 1-- Das ist ein Kommentar
Die folgenden Erörterungen treffen nur zu, wenn Sie eine MySQL-Version vor 3.23 laufen lassen:
Wenn Sie ein SQL-Programm in einer Textdatei haben, das
'--'-Kommentare enthält, sollten Sie
folgendes benutzen:
shell>replace " --" " #" < text-datei-mit-merkwuerigen-kommentaren.sql \| mysql datenbank
anstelle des üblichen:
shell> mysql datenbank < text-datei-mit-merkwuerdigen-kommentaren.sql
Sie können auch die Kommandodatei ``direkt'' editieren, um
die '--'-Kommentare zu
‘#’-Kommentaren zu machen:
shell> replace " --" " #" -- text-datei-mit-merkwuerdigen-kommentaren.sql
Machen Sie die Änderungen mit folgendem Befehl rückgängig:
shell> replace " #" " --" -- text-datei-mit-merkwuerdigen-kommentaren.sql
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.
Dieser Anhang listet die Features auf, für die wir eine Implementierung in MySQL geplant haben.
Alles auf dieser Liste gibt nur ungefähr die Reihenfolge wieder, in der es gemacht werden wird. Wenn Sie die Prioritäten beeinflussen wollen, registrieren Sie bitte eine Lizenz oder unterstützen Sie uns und teilen uns mit, was Sie schneller gemacht haben wollen. See Abschnitt 2.4.4, „MySQL-Lizenzpolitik“.
Geplant ist, dass wir in Zukunft den kompletten ANSI-SQL99-Standard unterstützen, aber mit einer Menge nützlicher Erweiterungen. Die Herausforderung liegt darin, dass durchzuführen, ohne Geschwindigkeitsvorteile zu opfern oder den Code zu kompromittieren.
Wir haben uns der Entwicklung von MySQL Version 4.0 zugewandt. Die meisten grundsätzlichen Dinge, die wir in Version 4.0 haben wollen, sind bereits gemacht. Das Ziel ist, den Rest der folgenden Features schnell einzubauen und dann zur Entwicklung von MySQL 4.1 überzugehen.
See Abschnitt 2.5, „MySQL 4.0 kurz und bündig“.
Der News-Abschnitt für 4.0 beinhaltet eine Liste der Features, die wir bereits im 4.0-Baum implementiert haben. See Abschnitt C.1, „Änderungen in Release 4.0.x (Entwicklung; Alpha)“.
Benutzern erlauben, die Startoptionen zu ändern, ohne den Server herunter fahren zu müssen.
Störsichere Replikation.
Mehr Funktionen für die Volltextsuche. See Abschnitt 7.8.3, „Neue Features der Volltextsuche in MySQL 4.0“.
Neuer Schlüssel-Cache
Neues Dateiformat für die Tabellendefinition
(.frm-Dateien). Das versetzt uns in die
Lage, nicht irgendwann keine Bits mehr zu haben, wenn wir
weitere Tabellenoptionen hinzufügen. Es wird nach wie vor
möglich sein, in 4.0 das alte
.frm-Dateiformat zu benutzen. Alle neu
erzeugten Tabellen werden jedoch das neue Format benutzen.
Das neue Dateiformat versetzt uns in die Lage, neue
Spaltentypen, mehr Optionen für Schlüssel und
FOREIGN KEY-Support hinzuzufügen.
Die Replikation sollte mit RAND() und
Benutzer-Variablen @var funktionieren.
Online-Datensicherung mit sehr geringen Performance-Einbussen. Das Online-Backup wird das Hinzufügen eines neuen Replikations-Slaves erleichtern, ohne dass man den Master herunter fahren muss.
Es zulassen, dass DELETE auf
MyISAM-Tabellen den Datensatz-Cache
benutzt. Um das zu tun, müssen wir den Thread-Cache für
Datensätze aktualisieren, wenn wir die
.MYD-Datei aktualisieren.
Zeichensatz-Festlegungen (Casts) und Syntax für die Handhabung mehrerer Zeichensätze.
Hilfe für alle Befehle des Clients.
Sichere Verbindungen (mit SSL).
SHOW COLUMNS FROM tabelle (der vom
mysql-Client benutzt für die Erweiterung
von Spaltennamen benutzt wird) sollte nicht die Tabelle
öffnen, sondern nur die Definitionsdatei. Das wird weniger
Speicher beanspruchen und sehr viel schneller sein.
Bei der Benutzung von SET CHARACTER SET
sollten wir die gesamte Anfrage übersetzen und nicht nur
Zeichenketten. Das würde Benutzern ermöglichen,
landesspezifische Zeichen auch in Datenbank-, Tabellen- und
Spaltenamen zu benutzen.
Hinzufügen einer portablen Schnittstelle zu
gethostbyaddr_r(), damit wir
ip_to_hostname() davon abhalten können,
andere Threads zu blockieren, während es DNS-Lookups
durchführt.
Hinzufügen der record_in_range()-Methode
zu MERGE-Tabellen, um den richtigen Index
auswählen zu können, wenn es viele gibt, aus denen
ausgewählt werden kann. Wir sollten auch die
info-Schnittstelle erweitern, um die Schlüsselverteilung
für jeden Index zu erhalten, wenn
analyze über alle Unter-Tabellen läuft.
SET SQL_DEFAULT_TABLE_TYPE=[MyISAM | INNODB | BDB |
HEAP].
Unteranfragen (Subqueries). select id from t where
grp in (select grp from g where u > 100)
Atomische Multi-Tabellen-Updates, zum Beispiel
update items,month set items.price=month.price
where items.id=month.id;;
Abgeleitete Tabellen (Derived Tables).
select a.col1, b.col2 from (select max(col1) as col1 from root_table ) a, other_table b where a.col1=b.col1
Das könnte erreicht werden, indem für die Dauer der Anfrage automatisch temporäre Tabellen für die abgeleiteten Tabellen erzeugt werden.
Hinzufügen eines PREPARE von Statements
und Senden von Parametern an mysqld.
Erweiterung des Client-Server-Protokolls, um Warnungen (Warnings) zu unterstützen.
Hinzufügen von Optionen zum Client-Server-Protokoll, um Fortschrittsanzeigen für lange laufende Kommandos zu erhalten.
Hinzufügen von Datenbank und echtem Tabellennamen (im Falle von Alias) zur MYSQL_FIELD-Struktur.
Nicht mehr als die festgelegte Anzahl von Threads zulassen, um MyISAM recover zeitgleich laufen zu lassen.
INSERT ... SELECT ändern, um optional
konkurrierende Inserts zu benutzen.
RENAME DATABASE implementieren. Damit das
sicher für alle Tabellen-Handler funktioniert, sollte es
wie folgt laufen:
Neue Datenbank anlegen.
Für jede Tabelle ein Umbenennen der Tabelle zu einer
anderen Datenbank durchführen, wie wir es schon mit dem
RENAME-Befehl machen.
Alte Datenbank löschen.
Die Original-Feldtypen zurückgeben, wenn SELECT
MIN(column)... GROUP BY ausgeführt wird.
Mehrfache Ergebnismengen (Multiple Result Sets).
Änderung des Protokolls, um Binärübertragung von Werten zu ermöglichen. Um das effizient zu machen, müssen wir eine API hinzufügen, die Bindung (Binding) von Variablen erlaubt.
mysqld.
Es soll möglich sein, long_query_time
mit einer Auflösung in Mikrosekunden festzulegen.
Hinzufügen eines konfigurierbaren Prompts zum
mysql-Kommandozeilen-Werkzeug, mit
Optionen wie Datenbank in Benutzung, Zeit und Datum ...
Hinzufügen von Bereichsüberprüfung (Range Checking) zu
MERGE-Tabellen.
myisampack-Code in den Server einlinken.
Portierung von MySQL auf BeOS.
Portierung von MySQL-Clients auf LynxOS.
Hinzufügen eines temporären Schlüssel-Puffer-Caches
während INSERT/DELETE/UPDATE, um den
vorherigen Zustand elegant wiederherstellen zu können, wenn
der Index voll wird.
Wenn ein ALTER TABLE auf eine Tabelle
durchgeführt wird, die per Symlink auf einer anderen
Festplatte ist, temporäre Tabellen auf dieser Festplatte
erzeugen.
Implementierung eines DATE/DATETIME-Typs,
der Zeitzonen-Informationen sauber handhabt, damit der
Umgang mit Datumswerten in verschiedenen Zeitzonen leichter
wird.
FreeBSD- und MIT-pThreads; nehmen schlafende Threads CPU in Anspruch?
Prüfen, ob gesperrte Threads CPU beanspruchen.
Configure reparieren, so dass man alle Bibliotheken (wie
MyISAM) ohne Threads kompilieren kann.
Hinzufügen einer Option, um regelmäßig die Schlüsselseiten (Key Pages) für Tabellen mit verzögerten Schlüsseln (Delayed Keys) zu löschen (flush), wenn Sie eine Weile nicht in Gebrauch waren.
Verknüpfungen (Join) auf Teile des Schlüssels zulassen (Optimierungsthema).
INSERT SQL_CONCURRENT und mysqld
--concurrent-insert sollen ein konkurrierendes
Insert am Ende der Datei machen, falls die Datei
lese-gesperrt ist.
FOREIGN-Key-Festlegungen in der
.frm-Datei speichern.
Kaskadierendes Löschen (DELETE)
Serverseitige Cursor.
Prüfen, ob lockd mit modernen
Linux-Kernels funktioniert; wenn nicht, müssen wir
lockd überarbeiten! Um das zu testen,
startet man mysqld mit
--enable-locking und läßt die
verschiedenen fork* test suits laufen. Sie sollten keine
Fehler produzieren, wenn lockd
funktioniert.
SQL-Variablen in LIMIT zulassen, wie
LIMIT @a,@b.
Aktualisierung von Variablen in
UPDATE-Statements zulassen, zum Beispiel:
UPDATE TABLE foo SET @a=a+b,a=@a, b=@a+c
Wenn Benutzervariablen aktualisiert werden, so ändern, dass
man sie mit GROUP BY benutzen kann wie in
folgendem Beispiel: SELECT id, @a:=count(*),
sum(sum_col)/@a FROM tabelle GROUP BY id.
Keine automatischen DEFAULT-Werte zu
Spalten hinzufügen. Fehler ausgeben, wenn ein
INSERT benutzt wird, dass keine Spalte
enthält, die keinen DEFAULT-Wert hat.
Caching von Anfragen und Ergebnissen. Das sollte als
separates Modul gemacht werden, das jede Anfrage prüft.
Falls diese Anfrage im Cache ist, soll das Cache-Ergebnis
zurückgegeben werden. Wenn man eine Tabelle aktualisiert,
sollte man so wenige Anfragen wie möglich aus dem Cache
entfernen. Das sollte eine große Geschwindigkeitssteigerung
auf Maschinen geben, die viel RAM haben und wo Anfragen of
wiederholt werden (wie WWW-Applikationen). Eine Idee wäre,
nur Anfrage des Typs SELECT CACHED ... zu
cachen.
libmysql.c überarbeiten, damit zwei
mysql_query()-Befehle in einer Zeile
stehen können, ohne dass Ergebnisse gelesen werden oder man
eine nette Fehlermeldung erhält, wenn man das tut.
Optimierung des BIT-Typs, so dass er 1
Bit aufnimmt (momentan nimmt BIT 1
Zeichen auf).
Prüfen, warum MIT-pThreads ctime() auf
einigen FreeBSD-Systemen nicht funktioniert.
Hinzufügen einer IMAGE-Option zu
LOAD DATA INFILE, damit
TIMESTAMP- und
AUTO_INCREMENT-Felder nicht aktualisiert
werden.
LOAD DATE INFILE.. UPDATE-Syntax
hinzufügen.
Wenn Daten bei Tabellen mit Primärschlüssel den Primärschlüssel enthalten, werden Einträge, die zu diesem Primärschlüssel passen, vom Rest der Spalten aktualisert. Spalten, die im herein kommenden Datenstrom NICHT enthalten sind, werden jedoch nicht berührt.
Bei Tabellen mit Primärschlüsseln, wo im herein
kommenden Datenstrom ein Teil des Schlüssels fehlt,
oder wenn kein Primärschlüssel eingegeben wird, wird
die Eingabe so behandelt wie jetzt schon LOAD
DATA INFILE ... REPLACE INTO.
LOAD DATA INFILE soll auch folgende
Syntax verstehen:
LOAD DATA INFILE 'datei.txt' INTO TABLE tabelle TEXT_FIELDS (text_feld1, text_feld2, text_feld3) SET tabelle_feld1=concatenate(text_feld1, text_feld2), tabelle_feld3=23 IGNORE text_feld3 Das kann benutzt werden, um zusätzliche Spalten in der Textdatei zu überspringen oder um Spalten basierend auf Ausdrücken in den gelesenen Daten zu aktualisieren ...
LOAD DATA INFILE 'datei' INTO TABLE 'tabelle'
ERRORS TO err_tabelle Das würde bewirken, dass
alle Fehler und Warnungen in der err_tabelle mitgeschrieben
werden. Diese Tabelle hätte etwa folgende Struktur:
zeile_nummer - Zeilennummer in der Datendatei fehler_nachricht - die Fehler-/Warnungs-Nachricht und vielleicht daten_zeile - die Zeilennummer der Datendatei
Hinzufügen von echter
VARCHAR-Unterstützung (gibt es schon in
MyISAM).
Automatische Ausgabe von mysql an
Netscape.
LOCK DATABASES. (mit vielerlei Optionen)
Ändern wie Sortierung Speicher alloziert, um bessere Speicherausnutzung zu erhalten.
DECIMAL- und
NUMERIC-Typen können keine
exponentiellen Zahlen lesen;
Field_decimal::store(const char *from,uint
len) muss neu kodiert werden, um das zu beheben.
mysql.cc überarbeiten, damit weniger
malloc()-Aufrufe durchgeführt werden,
wenn Feldnamen gehasht werden.
Funktionen: ADD_TO_SET(wert,set) und REMOVE_FROM_SET(wert,set)
Benutzung von t1 JOIN t2 ON ... und
t1 JOIN t2 USING ... hinzufügen.
Momentan kann man diese Syntax nur mit LEFT
JOIN benutzen.
Volle Unterstützung für unsigned long
long-Typen hinzufügen.
Viele weitere Variablen für show status.
Zähler für:
INSERT-/DELETE-/UPDATE-Statements.
Gelesene und aktualisierte Datensätze. Select auf 1 Tabelle
und Selects mit Joins. Durchschnittliche Anzahl von Tabellen
in Selects. Anzahl von ORDER BY- und
GROUP BY-Anfragen.
Wenn man mysql mitten in einer Anfrage
abbricht, sollte man eine neue Verbindung herstellen und die
alte, laufende Anfrage killen. Alternativ könnte man den
Versuch unternehmen, so etwas im Server zu entdecken.
Eine Handler-Schnittstelle für Tabelleninformation
hinzufügen, damit man sie als Systemtabelle benutzen kann.
Das wäre ein bisschen langsam, wenn man Informationen über
alle Tabellen abfragt, aber sehr flexibel. SHOW
INFO FROM tabelle für Basisinformationen über
Tabellen sollte implementiert werden.
Unterstützung für UNICODE hinzufügen.
NATURAL JOIN und UNION
JOIN.
Anfragen wie select a from crash_me left join
crash_me2 using (a) zulassen; in diesem Fall wird
angenommen, dass a aus der crash_me-Tabelle kommt.
Überarbeitung, damit ON und
USING mit dem
JOIN-Verknüpfungstyp funktioniert.
Oracle-mäßiges CONNECT BY PRIOR ..., um
hierarchische Strukturen zu durchsuchen.
mysqladmin copy datenbank neue_datenbank.
-- Erfordert, dass mysqld der COPY-Befehl
hinzugefügt wird.
Prozessliste sollte die Anzahl von Anfragen pro Thread zeigen.
SHOW HOSTS zur Informationsausgaben über
den Hostnamen-Cache.
Format von DATETIME ändern, um
Bruchteile von Sekunden zu speichern.
Alle fehlenden ANSI92- und ODBC 3.0-Typen hinzufügen.
Für berechnete Spalten Tabellennamen von leerer
Zeichenkette zu NULL ändern.
'Item_copy_string' nicht auf numerische Werte anwenden, um
Zahl->Zeichenkette->Zahl-Umwandlung zu vermeiden, im
Falle von: SELECT COUNT(*)*(id+0) FROM tabelle
GROUP BY id
Benutzung der neuen GNU-regexp-Bibliothek anstelle der aktuellen ermöglichen (die GNU-Bibliothek sollte viel schneller sein als die alte).
ALTER TABLE sollte nicht mehr Clients
abbrechen, die INSERT DELAYED ausführen.
So überarbeiten, dass, wenn Spalten, auf die in einer
UPDATE-Klausel verwiesen wird, die alten
Werte enthalten, bevor das Update begonnen wird.
myisamchk, REPAIR und
OPTIMIZE TABLE sollten in der Lage sein,
mit Fällen umzugehen, wo die Daten und / oder Indexdateien
symbolische Links sind.
Simulation von
pread()/pwrite() auf
Windows einarbeiten, um konkurrierende Inserts zu
ermöglichen.
Ein Logdatei-Analyzer, aus dem Informationen herausgefiltert (geparst) werden können, welche Tabellen am häufigsten angesprochen werden, wie oft Verknüpfungen (Joins) mit mehreren Tabellen ausgeführt werden usw. Es sollte Benutzern helfen, Bereiche oder Dinge im Tabellenentwurf zu erkennen, die optimiert werden können, um sehr viel effizientere Anfragen auszuführen.
Add SUM(DISTINCT)
ANY()-,EVERY()- und
SOME()-Gruppierungsfunktionen
hinzufügen. In ANSI-SQL funktionieren diese auf boolsche
Spalten, aber wir können sie so erweitern, dass sie mit
beliebigen Spalten / Ausdrücken funktionieren, indem wir
folgendes anwenden: wert == 0 -> FALSE und wert <>
0 -> TRUE.
So überarbeiten, dass MAX(column) vom
selben Typ ist wie der Spaltentyp.
create tabelle t1 (a DATE); insert into t1 values (now()); create tabelle t2 select max(a) von t1; show columns from t2;
Eine nette Syntax für ein Statement entwickeln, dass auf
eine Zeile ein UPDATE ausführt, wenn sie
existiert, und eine neue Zeile einfügt
(INSERT), wenn sie nicht existiert (so
wie REPLACE bei INSERT
/ DELETE funktioniert).
Funktion implementieren:
get_changed_tables(timeout,table1,table2,...)
Lesen durch Tabellen so ändern, das memmap benutzt wird, falls möglich. Momentan benutzen nur komprimierte Tabellen memmap.
Ein neues Zugriffsrecht
'Show_priv' für
SHOW-Befehle hinzufügen.
Den automatischen Zeitstempel-Code netter machen.
Zeitstempel zum Update-Log hinzufügen mit SET
TIMESTAMP=#;
An manchen Stellen read/write mutex benutzen, um mehr Geschwindigkeit zu erhalten.
Volle Unterstützung von Fremdschlüsseln. Wahrscheinlich wird man zuerst einmal eine prozedurale Sprache implementieren wollen.
Einfache Sichten (Views; zunächst auf eine Tabelle, später auf jeden beliebigen Ausdruck).
Automatisches Schließen einiger Tabellen, wenn eine Tabelle, eine temporäre Tabelle oder eine temporäre Datei einen Fehler 23 bekommt (nicht genug offene Dateien).
Wenn ein Feld=# gefunden wird, alle Vorkommen von Feld auf # setzen. Momentan wird das nur in einigen einfachen Fällen gemacht.
Alle konstanten Ausdrücke mit berechneten Ausdrücken austauschen, falls möglich.
schlüssel = ausdruck optimieren. Momentan wird nur schlüssel = feld oder schlüssel = konstante optimiert.
Einige der Copy-Funktionen verbinden, um netter Code zu erhalten.
sql_yacc.yy in einen Inline-Parser
umändern, um die Größe zu reduzieren und bessere
Fehlermeldungen zu erhalten (5 Tage).
Den Parser so ändern, dass er nur eine Regel pro unterschiedlicher Anzahl von Argumenten in Funktionen benutzt.
Die Benutzung von vollen Berechnungsnamen (full calculation names) im ORDER-Teil (order part). (Für ACCESS97)
UNION, MINUS,
INTERSECT und FULL OUTER
JOIN. (Momentan wird nur LEFT OUTER
JOIN unterstützt.)
UNIQUE bei Feldern zulassen, die
NULL sein können.
SQL_OPTION MAX_SELECT_TIME=# um einer
Anfrage eine Zeitbeschränkung zu setzen.
Make the update log to a Datenbank. Update soll in eine Datenbank loggen.
Negative LIMIT-Parameter, um Daten vom
Ende abrufen zu können.
Alarm around client connect/read/write Funktionen.
Bitte beachten sie die Änderungen in
safe_mysqld: Nach FSSTND (woran sich
Debian versucht zu halten) sollten PID-Dateien als
/var/run/<progname>.pid angelegt
werden und Log-Datei in /var/log. Es
wäre nett, wenn man "DATADIR" in die erste Deklaration von
"pidfile" und "log" packen könnte, damit die Unterbringung
dieser Dateien mit einem einzigen Statement geändert werden
könnte.
Einem Client erlauben, Mitloggen anzufordern.
Benutzung von zlib() für
gzip-te Dateien in LOAD DATA
INFILE zulassen.
Sortieren und Gruppieren von BLOB-Spalten
in Ordnung bringen (teilweise bereits gelöst).
Gespeicherte Prozeduren. Wird aktuell nicht als sehr wichtig erachtet, weil gespeicherte Prozeduren noch nicht sehr standardisiert sind. Ein weiteres Problem besteht darin, dass es echte gespeicherte Prozeduren dem Optimierer viel schwerer machen und dass in vielen Fällen das Ergebnis langsamer sein wird als vorher. Auf der anderen Seite werden wir versuchen, eine einfache (atomische) Update-Sprache hinzuzufügen, die benutzt werden kann, um Schleifen und ähnliches im MySQL-Server zu schreiben.
So ändern, dass Semaphore benutzt werden, wenn Threads gezählt werden. Man sollte zuerst eine Semaphor-Bibliothek zu MIT-pThreads implementieren.
Keinen neuen AUTO_INCREMENT-Wert
zuweisen, wenn eine Spalte auf 0 gesetzt wird. Statt dessen
NULL setzen.
Volle Unterstützung von Verknüpfungen
(JOIN) mit Klammern.
Als Alternative für einen Thread pro Verbindung einen Pool von Threads verwalten, der die Anfragen handhabt.
Einem gestatten, mehr als eine Sperre (Lock) mit
GET_LOCK zu erhalten. Wenn man das tut,
muss man die möglichen Deadlocks handhaben, die diese
Änderung einführen wird.
Zeitangaben stehen für den Umfang der Arbeit, nicht für echte Zeit.
This is a translation of the MySQL Reference Manual that can be found at dev.mysql.com. The original Reference Manual is in English, and this translation is not necessarily as up to date as the English version.