Manuals > MySQL-Referenzhandbuch für Version 4.1.1-alpha - 2 Vorbemerkungen zum deutschen Handbuch

2 Vorbemerkungen zum deutschen Handbuch

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, handbuch@mysql.com

Berlin, im Februar 2002

Stefan Hinz, iConnect GmbH Berlin

2.1 Über dieses Handbuch

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 section C 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 section 2.4.2 Copyrights und Lizenzen, die von MySQL verwendet werden..

2.1.1 Konventionen in diesem Handbuch

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-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:

Um csh auszuführen, würden Sie folgende Sequenz ausführen:

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:

Wenn Sie ein ähnliches Statement eingeben wollen, müssen Sie Ihre eigenen Datenbank-, Tabellen- und Spaltennamen eingeben, zum Beispiel wie folgt:

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:

Im Kontext der COUNT() Funktion hingegen könnte dasselbe Statement wie folgt geschrieben werden:

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:

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 `]'):

Wenn genau ein Element aus einer Anzahl von Möglichkeiten ausgewählt werden muss, werden die Alternativen innerhalb geschweifter Klammern aufgelistet (`{' und `}'):

2.2 Was ist MySQL?

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 section 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 section 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 section 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.

2.2.1 Die wichtigsten Features von MySQL

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 section 9 MySQL-APIs.
• Läuft auf vielen verschiedenen Plattformen. See section 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 section 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 section 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 section 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 `@ringaccent', `ä' 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 section 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 section 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.

2.2.2 Wie stabil ist MySQL?

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 section 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 section 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.

2.2.3 Wie groß können MySQL-Tabellen sein?

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:

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 section 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 section 7.5.3 CREATE TABLE-Syntax. Sie können diese auch später setzen, mit ALTER TABLE. See section 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 section 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 section 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 section 8.2 MERGE-Tabellen.

2.2.4 Jahr-2000-Konformität

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:

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 section 2.2.4 Jahr-2000-Konformität wegen der Regeln, die MySQL anwendet, wenn mehrdeutige Datumsangaben gemacht werden (Datumsangaben, die zweistellige Jahreswerte verwenden).

2.3 Was ist MySQL AB?

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 section 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.

2.3.1 Geschäftsmodell und Dienstleistungen von MySQL AB

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.

2.3.1.1 Support

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 section 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.

2.3.1.2 Training und Zertifizierung

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.

2.3.1.3 Beratung

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.

2.3.1.4 Kommerzielle Lizenzen

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 section 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.

2.3.1.5 Partnerprogramme

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 section 2.4.3 MySQL-AB-Logos und -Schutzmarken.

2.3.1.6 Werbung

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.

2.3.1.7 Kontaktinformationen

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 section 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 section 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 section 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 section 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 section 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 section 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.

2.4 MySQL Support and Lizensierung

Dieser Abschnitt beschreibt die MySQL Support und Lizensierungsvereinbarungen

2.4.1 Support den MySQL AB anbietet

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.

Technischer Support ist wie eine Lebensversicherung. Sie können jahrelang ohne solches glücklich sein, doch wenn die Stunde schlägt, kann es zu spät sein, diese(n) zu kaufen! Wenn Sie den MySQL-Server für wichtige Applikationen nutzen und plötzlich Problemen begegnen, kann es möglicherweise zu lange dauern, alle Antworten selbst herauszufinden. Es kann daher sein, dass Sie unmittelbaren Zugriff auf die erfahrensten MySQL-Problemlöser benötigen, und da

2.4.2 Copyrights und Lizenzen, die von MySQL verwendet werden.

MySQL AB besitzt das Copyright des MySQL Quellcodes, der MySQL Logos and Schutzmarken und dieses Handbuch See section 2.3 Was ist MySQL AB?. Es gibt einige verschiedene Lizenzen, die für die MySQL Distribution relevant sind:

1. Der MySQL-spezifische Quelltext, der benötigt wird, um die mysqlclient-Bibliothek zu kompilieren, ist unter der LGPL lizensiert. Programme im `client'-Verzeichnis sind GPL. Jede Datei hat einen Header, aus dem ersichtlich ist, welches Copyright für diese Datei gilt.
2. Die Client-Bibliothek und die (GNU getopt)-Bibliothek werden von der ``GNU LIBRARY GENERAL PUBLIC LICENSE'' abgedeckt. See section I GNU LESSER GENERAL PUBLIC LICENSE.
3. Der gesamte Quelltext des Servers und der (GNU readline)-Bibliothek werden von der ``GNU GENERAL PUBLIC LICENSE'' abgedeckt. See section H GNU GENERAL PUBLIC LICENSE. Diese findet sich unter anderem als Datei `COPYING' in den Distributionen.
4. Einige Teile des Quelltextes (die regexp-Bibliothek) werden von einem Copyright in Berkeley-Art abgedeckt.
5. Ä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.
6. 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 den Privaten Gebrauch 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 arbeiten beachten Sie bitte section 2.4.4 MySQL-Lizenzpolitik. Siehe auch section 2.4.3 MySQL-AB-Logos und -Schutzmarken.

2.4.2.1 Verwendung des MySQL Servers unter einer kommerziellen Lizenz

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.

2.4.2.2 Einen Webserver betreiben, der MySQL benutzt

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.

2.4.3 MySQL-AB-Logos und -Schutzmarken

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.

2.4.3.1 Das Original-MySQL-Logo

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.

2.4.3.2 MySQL-Logos die ohne schriftliche Erlaubnis benutzt werden dürfen

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.

2.4.3.3 Wann Sie eine Erlaubnis für die Benutzung des MySQL-Logos benötigen

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.

2.4.3.4 MySQL-AB-Partnerschafts-Logos

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 section 2.3.1.5 Partnerprogramme nach.

2.4.4 MySQL-Lizenzpolitik

Die formalen Bedingungen der GPL-Lizenz stehen unter section H 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.

Eine Lizenz wird NICHT benötigt:

• Sie benötigen keine Lizenz, wenn Sie den Client-Code in kommerzielle Programme einschliessen. Der Client-Teil von MySQL unterliegt der LGPL GNU Library General Public License-Lizenz. Der mysql-Kommandozeilen-Client beinhaltet Code der readline-Bibliothek, die unter GPL steht.
• Wenn Sie für Ihre Art der Benutzung von MySQL keine Lizenz benötigen, aber MySQL mögen und die weitere Entwicklung fördern wollen, sind Sie herzlich eingeladen, in jedem Fall eine Lizenz zu erwerben.
• Wenn Sie MySQL in einem kommerziellen Zusammenhang benutzen und davon profitieren, bitten wir Sie, dass Sie die Weiterentwicklung von MySQL fördern, indem Sie einen bestimmten Grad von Support kaufen. Wir meinen, dass es vernünftig ist, wenn wir Sie bitten, MySQL zu unterstützen, wenn MySQL Ihren Geschäften hilft. (Ansonsten würde es bei Support-Anfragen bedeuten, dass Sie nicht nur etwas für umsonst benutzen, in das wir eine Menge Arbeit gesteckt haben, sondern dass Sie uns auch noch auffordern, kostenlosen Support zu liefern.)

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 section 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.

2.4.4.1 Benutzung des Worts MySQL in Druckmaterialien oder

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.

2.4.4.2 Benutzung des Worts MySQL in Unternehmens- und

Produktnamen

Die Benutzung des Worts MySQL in Produkt- und Unternehmensnamen oder in Internet-Domänen-Namen ist nur mit vorheriger schriftlicher Erlaubnis durch MySQL AB gestattet.

2.5 MySQL 4.0 kurz und bündig

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.

2.5.1 Schritt für Schritt

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.

2.5.2 Für den sofortigen Entwicklungseinsatz

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.

2.5.3 Eingebettetes MySQL

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 section 9.4.9 libmysqld, die eingebettete MySQL-Server-Bibliothek.

2.5.4 Weitere ab MySQL 4.0.0 verfügbare Features

• 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.

2.5.5 Zukünftige Features in MySQL 4.0

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.

2.5.6 MySQL 4.1, das folgende Entwicklungs-Release

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.

2.6 MySQL-Informationsquellen

2.6.1 MySQL-Portale

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.

2.6.2 MySQL-Mailing-Listen

Dieser Abschnitt führt Sie in die MySQL-Mailing-Listen ein und zeigt einige Richtlinien und ihre Benutzung auf.

2.6.2.1 Die MySQL-Mailing-Listen

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 section 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.

2.6.2.2 Wie man Fragen stellt oder Bugs berichtet

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.

2.6.2.3 Wie man Bugs oder Probleme berichtet

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 section E.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 section 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 section E.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 section D 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 section 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 section 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 section 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 section 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 section 9.3.4 Wie Sie Probleme mit MyODBC berichten.

Lösungen für häufig auftretende Probleme siehe See section 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!

2.6.2.4 Richtlinien für die Beantwortung von Fragen auf der Mailing-Liste

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!

2.7 Wie Standard-kompatibel ist MySQL?

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.

2.7.1 An welche Standards hält sich MySQL?

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.

2.7.2 MySQL im ANSI-Modus laufen lassen

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 section 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.

2.7.3 MySQL-Erweiterungen zu ANSI SQL92

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:

Wenn Sie hinter '!' die Versionsnummer angeben, wird die Syntax nur ausgeführt, wenn die MySQL-Version gleich oder neuer als die benutzte Versionsnummer ist:

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 section 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 section 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 section 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 section 7.5.4 ALTER TABLE-Syntax.
• Die Benutzung von RENAME TABLE. See section 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 section 7.4.9 LOAD DATA INFILE-Syntax.
• Die ANALYZE TABLE-, CHECK TABLE-, OPTIMIZE TABLE- und REPAIR TABLE-Statements.
• Das SHOW-Statement. See section 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 section 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 section 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 section 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 section 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;

2.7.4 MySQL-Unterschiede im Vergleich zu ANSI SQL92

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 section 2.7.4.8 `--' als Beginn eines Kommentars.
• Bei VARCHAR-Spalten werden Leerzeichen am Ende entfernt, wenn der Wert gespeichert wird. See section 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 section 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 section 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.

2.7.4.1 Sub-Selects

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:

Das kann wie folgt umgeschrieben werden:

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:

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:

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:

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.

2.7.4.2 SELECT INTO TABLE

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 section 7.4.3.1 INSERT ... SELECT-Syntax.

Alternativ können Sie SELECT INTO OUTFILE... oder CREATE TABLE ... SELECT benutzen, um Ihre Probleme zu lösen.

2.7.4.3 Transaktionen

Weil MySQL heutzutage Transaktionen unterstützt, gelten die folgenden Erörterungen nur, wenn Sie nur Tabellentypen benutzen, die nicht transaktionssicher sind. See section 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 section 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 section 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!

2.7.4.4 Gespeicherte Prozeduren und Trigger

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 section 2.8 MySQL und die Zukunft (das TODO).

2.7.4.5 Fremdschlüssel

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):

See section 7.4.1.1 JOIN-Syntax. See section 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 section 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.

2.7.4.6 Warum wir Fremdschlüssel nicht implementiert haben

Viele Leute, die Datenbanken unterrichten und programmieren, sind der festen Meinung, dass referentielle Integrität durch den Datenbank-Server erzwungen werden sollte. In der Tat ist dieser Ansatz in vielen Fällen sehr hilfreich. In vielen Gesprächen mit Datenbankbenutzern haben wir jedoch festgestellt, dass Fremdschlüssel oft missbraucht werden, was schwer- wiegende Probleme verursachen kann. Selbst wenn sie in korrekter Weise benutzt werden, sind sie keine magische Lösung für das Problem referentieller Integrität, obwohl sie die Dinge in einigen Fällen einfacher gestalten.

Wegen der obigen Beobachtungen haben wir der Implementation von Fremdschlüsseln keine hohe Priorität zugewiesen. Unsere Benutzerbasis bestand bislang zumeist aus Entwicklern, denen es nichts ausmachte, referentielle Integrität im Code der Applikation zu erzwingen, und die dies sogar bevorzugten, weil es ihnen mehr Kontrolle gab.

In den letzten Jahren hat sich unsere Benutzerbasis jedoch um einiges ausgeweitet. Mittlerweile haben wir viele Benutzer, die es schätzen würden, wenn MySQL erzwungene referentielle Integrität implementiert hätte. Aus diesem Grund werden wir Fremdschlüssel in naher Zukunft implementieren. Allerdings können wir zur Zeit noch kein definitives Auslieferungsdatum nennen.

Einige Vorteile der Erzwingung von Fremdschlüsseln:

• Einen sauberen Entwurf der Beziehungen vorausgesetzt machen es Fremdschlüssel-Restriktionen schwieriger für einen Programmierer, Inkonsistenzen in eine Datenbank einzuführen.
• Wenn kaskadierende Updates und Deletes benutzt werden können, kann dies den Client-Code vereinfachen.
• Sauber entworfene Fremdschlüssel-Regeln sind hilfreich, Beziehungen zwischen Tabellen zu dokumentieren.

Nachteile:

• MySQL unterstützt noch keine erzwungene referentielle Integrität. Wenn Ihre Applikation also davon abhängt, können Sie sie solange nicht mit MySQL benutzen, bis wir dieses Feature implementieren.
• Fehler, die beim Entwurf von Schlüsselbeziehungen leicht zu machen sind, können schwer wiegende Probleme verursachen, zum Beispiel Zirkelbezüge oder eine falsche Kombination kaskadierender Deletes.
• Eine sauber geschriebene Applikation wird intern sicherstellen, dass sie referentielle Integritäts-Restriktionen nicht verletzt, bevor sie mit einer Anfrage fortfährt. Deshalb werden zusätzliche Überprüfungen auf Datenbankebene solche Applikationen nur verlangsamen.
• Es ist nichts Ungewöhnliches, dass ein Datenbankadministrator eine so komplexe Topologie von Beziehungen einführt, dass es sehr schwierig, wenn nicht gar unmöglich wird, einzelne Tabellen zu sichern oder wiederherzustellen.

2.7.4.7 Sichten (Views)

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 section 5.2 Allgemeine Sicherheitsthemen und das MySQL-Zugriffsberechtigungssystem.

2.7.4.8 `--' als Beginn eines Kommentars

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 section 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:

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:

anstelle des üblichen:

Sie können auch die Kommandodatei ``direkt'' editieren, um die `--'-Kommentare zu `#'-Kommentaren zu machen:

Machen Sie die Änderungen mit folgendem Befehl rückgängig:

2.7.5 Bekannte Fehler und Design-Unzulänglichkeiten in MySQL

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.

2.8 MySQL und die Zukunft (das TODO)

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 section 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.

2.8.1 Dinge, die in Version 4.0 enthalten sein sollten

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 section 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 section D.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 section 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].

2.8.2 Dinge, die in naher Zukunft erledigt werden müssen

• 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 spanPARE 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).

2.8.3 Dinge die irgendwann gemacht werden müssen

• 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.

2.8.4 Ein paar Dinge, für deren Umsetzung wir keine Pläne haben

• Nichts; auf lange Sicht planen wir, voll ANSI-92- / ANSI-99-kompatibel zu sein.

Go to the first, previous, next, last section, table of contents.