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


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:

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:

Die Fallstricke einer Übersetzung stecken allerdings in den Details:

Richtig spannend wird die Übersetzung bei Wörtern, die in der deutschen Fachsprache zumeist englisch verwendet werden, obwohl es passende deutsche Entsprechungen gibt:

Alle diese Entsprechungen, bei denen die deutsche Sprache eher in Vergessenheit geraten ist, wurden zweisprachig aufgenommen. Beispiele:

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> geben sie hier ein shell-kommando ein
mysql> geben sie hier ein mysql-kommando ein

Shell-Befehle werden mit der Bourne-Shell-Syntax dargestellt. Wenn Sie eine csh-Shell benutzen, müssen die Befehle evtl. etwas anders eingegeben werden. Das folgende Beispiel zeigt, wie mit der Bourne-Shell eine Umgebungsvariable gesetzt wird und anschließend ein Befehl abgesetzt wird:

shell> VARNAME=wert irgendein_befehl

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

shell> setenv VARNAME wert
shell> irgendein_befehl

Oft müssen Datenbank-, Tabellen- und Spaltennamen in konkreten Befehlen ersetzt werden. Um anzuzeigen, dass eine solche Ersetzung notwendig ist, benutzt dieses Handbuch db_name, tbl_name und col_name. Sie könnten zum Beispiel folgendes Statement sehen:

mysql> SELECT spalten_name FROM datenbank_name.tabellen_name;

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

mysql> SELECT autor_name FROM bibliothek.autorenliste;

SQL-Statements können in Groß- und Kleinschreibung geschrieben werden. Wenn dieses Handbuch SQL-Statements darstellt, wird Großschreibung verwendet, um spezielle Schlüsselworte in diesem Kontext hervorzuheben. Kleinschreibung wird für den Rest des Statements verwendet. Folgendes könnten Sie im Kontext des SELECT Statements sehen:

mysql> SELECT count(*) FROM tabellen_name;

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

mysql> select COUNT(*) from tabellen_name;

Wenn keine besondere Hervorhebung beabsichtigt wird, werden alle Schlüsselworte in Großschreibung dargestellt.

In Syntax-Beschreibungen werden eckige Klammern (`[' und `]') benutzt, um wahlfrei (optionale) Wörter oder Klauseln anzuzeigen:

DROP TABLE [IF EXISTS] tabellen_name

Wenn ein Syntaxelement aus einer Anzahl von Alternativen besteht, werden die Alternativen durch gerade Striche (`|') voneinander getrennt. Wenn genau ein Element aus einer Anzahl von Möglichkeiten ausgewählt werden (kann), werden die Alternativen mit eckigen Klammern aufgelistet (`[' und `]'):

TRIM([[BOTH | LEADING | TRAILING] [remstr] FROM] str)

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

{DESCRIBE | DESC} tbl_name {col_name | wild}

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:

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 -- Beta
Diese wurden MySQL kürzlich hinzu gefügt. Sie scheinen gut zu funktionieren und können nach einigen anfänglichen Tests benutzt werden.
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:

Betriebssystem Dateigrößen-Beschränkung
Linux-Intel 32 bit 2G, 4G oder mehr, abhängig von der Linux-Version
Linux-Alpha 8T (?)
Solaris 2.5.1 2G (möglich sind 4G mit Patch)
Solaris 2.6 4G
Solaris 2.7 Intel 4G
Solaris 2.7 ULTRA-SPARC 8T (?)

Auf Linux 2.2 kann man größere Tabellen als 2G benutzen, wenn man den LFS-Patch für das ext2 Dateisystem benutzt. Auf Linux 2.4 existiert zusätzlich ein Patch für das ReiserFS, um Unterstützung für große Dateien zu erhalten.

Letztlich wird die Tabellengröße für MySQL normalerweise durch das Betriebssystem begrenzt.

Vorgabemäßig haben MySQL-Tabellen eine maximale Größe von etwa 4G. Sie können die maximale Tabellengröße für eine Tabelle mit dem SHOW TABLE STATUS-Befehl überprüfen oder mit myisamchk -dv tabellen_name. See 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:

Probleme können Sie bekommen, wenn Sie MySQL mit Applikationen benutzen, die MySQL auf eine Art benutzen, die nicht Jahr-2000-sicher ist. Zum Beispiel speichern oder ändern viele alte Applikationen Jahresangaben, indem sie zweistellige Werte benutzen (was mehrdeutig ist), anstatt vierstellige Werte zu nehmen. Dieses Problem kann durch Applikationen verschlimmert werden, die Werte wie 00 oder 99 als Anzeiger ``fehlender'' Werte benutzen.

Leider sind diese Probleme möglicherweise schwer zu beheben, weil verschiedene Applikationen von unterschiedlichen Programmierern geschrieben sein können, von denen jeder einen anderen Satz von Konventionen und Funktionen benutzt haben kann, was die Handhabung von Datumsangaben betrifft.

Hier ist eine einfache Demonstration, die zeigt, dass MySQL keine Probleme mit Datumsangaben bis zum Jahr 2030 hat:

mysql> DROP TABLE IF EXISTS y2k;
Query OK, 0 rows affected (0.01 sec)

mysql> CREATE TABLE y2k (date date, date_time datetime, time_stamp timestamp);
Query OK, 0 rows affected (0.00 sec)

mysql> INSERT INTO y2k VALUES 
    -> ("1998-12-31","1998-12-31 23:59:59",19981231235959),
    -> ("1999-01-01","1999-01-01 00:00:00",19990101000000),
    -> ("1999-09-09","1999-09-09 23:59:59",19990909235959),
    -> ("2000-01-01","2000-01-01 00:00:00",20000101000000),
    -> ("2000-02-28","2000-02-28 00:00:00",20000228000000),
    -> ("2000-02-29","2000-02-29 00:00:00",20000229000000),
    -> ("2000-03-01","2000-03-01 00:00:00",20000301000000),
    -> ("2000-12-31","2000-12-31 23:59:59",20001231235959),
    -> ("2001-01-01","2001-01-01 00:00:00",20010101000000),
    -> ("2004-12-31","2004-12-31 23:59:59",20041231235959),
    -> ("2005-01-01","2005-01-01 00:00:00",20050101000000),
    -> ("2030-01-01","2030-01-01 00:00:00",20300101000000),
    -> ("2050-01-01","2050-01-01 00:00:00",20500101000000);
Query OK, 13 rows affected (0.01 sec)
Records: 13  Duplicates: 0  Warnings: 0

mysql> SELECT * FROM y2k;
+------------+---------------------+----------------+
| date       | date_time           | time_stamp     |
+------------+---------------------+----------------+
| 1998-12-31 | 1998-12-31 23:59:59 | 19981231235959 |
| 1999-01-01 | 1999-01-01 00:00:00 | 19990101000000 |
| 1999-09-09 | 1999-09-09 23:59:59 | 19990909235959 |
| 2000-01-01 | 2000-01-01 00:00:00 | 20000101000000 |
| 2000-02-28 | 2000-02-28 00:00:00 | 20000228000000 |
| 2000-02-29 | 2000-02-29 00:00:00 | 20000229000000 |
| 2000-03-01 | 2000-03-01 00:00:00 | 20000301000000 |
| 2000-12-31 | 2000-12-31 23:59:59 | 20001231235959 |
| 2001-01-01 | 2001-01-01 00:00:00 | 20010101000000 |
| 2004-12-31 | 2004-12-31 23:59:59 | 20041231235959 |
| 2005-01-01 | 2005-01-01 00:00:00 | 20050101000000 |
| 2030-01-01 | 2030-01-01 00:00:00 | 20300101000000 |
| 2050-01-01 | 2050-01-01 00:00:00 | 00000000000000 |
+------------+---------------------+----------------+
13 rows in set (0.00 sec)

Das zeigt, dass die DATE- und DATETIME-Typen für zukünftige Datumsangaben keine Probleme bereiten werden (sie handhaben Datumsangaben bis zum Jahr 9999).

Der TIMESTAMP-Typ, der zur Speicherung der aktuellen Zeit benutzt wird, hat nur einen Bereich bis zu 2030-01-01. TIMESTAMP hat einen Bereich von 1970 bis 2030 auf 32-Bit-Maschinen (vorzeichenbehafteter Wert). Auf 64-Bit-Maschinen handhabt dieser Spaltentyp bis zu 2106 (vorzeichenloser Wert).

Obwohl MySQL Jahr-2000-kompatibel ist, sind Sie dafür verantwortlich, mehrdeutige Eingaben zu vermeiden. Siehe 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:

MySQL AB und die Leute von MySQL AB:

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:

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/support/arrangements/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. 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/downloads/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:

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:

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:

Eine Lizenz wird NICHT benötigt:

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

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:

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:

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:

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:

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:

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:

SELECT /*! STRAIGHT_JOIN */ col_name FROM tabelle1, tabelle2 WHERE ...

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

CREATE /*!32302 TEMPORARY */ TABLE (a int);

Je höher bedeutet, wenn Sie Version 3.23.02 oder neuer haben, wird MySQL das TEMPORARY-Schlüsselwort benutzen.

MySQL-Erweiterungen sind:

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:

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:

SELECT * FROM tabelle1 WHERE id IN (SELECT id FROM tabelle2);

Das kann wie folgt umgeschrieben werden:

SELECT tabelle1.* FROM tabelle1,tabelle2 WHERE tabelle1.id=tabelle2.id;

Die Anfragen:

SELECT * FROM tabelle1 WHERE id NOT IN (SELECT id FROM tabelle2);
SELECT * FROM tabelle1 WHERE NOT EXISTS (SELECT id FROM tabelle2 where tabelle1.id=tabelle2.id);

Können wie folgt umgeschrieben werden:

SELECT tabelle1.* FROM tabelle1 LEFT JOIN tabelle2 ON tabelle1.id=tabelle2.id where tabelle2.id IS NULL

Für kompliziertere Unteranfragen (Subqueries) können Sie oft temporäre Tabelle anlegen, die die Unteranfrage enthalten. In einigen Fällen wird diese Option allerdings nicht funktionieren. Am häufigsten treten diese Fälle mit DELETE-Statements auf, wofür Standard-SQL keine Verknüpfungen (Joins) unterstützt. Für solche Situationen sind zwei Optionen verfügbar, solange MySQL noch keine Unteranfragen unterstützt.

Die erste Option besteht darin, eine prozedurale Programmiersprache (wie PHP oder Perl) zu benutzen, um eine SELECT-Anfrage zu erhalten, die die Primärschlüssel enthält, die benötigt werden, um die entsprechenden Datensätze zu löschen, und dann diese Werte zu benutzen, um das DELETE-Statement zu formulieren (DELETE FROM ... WHERE ... IN (key1, key2, ...)).

Die zweite Option besteht darin, interaktives SQL zu benutzen, um automatisch eine Reihe von DELETE-Statements zu formulieren, indem die MySQL-Erweiterung CONCAT() benutzt wird (anstelle des Standard-Operators ||). Beispiel:

SELECT CONCAT('DELETE FROM tabelle1 WHERE pkid = ', tabelle1.pkid, ';')
  FROM tabelle1, tabelle2
 WHERE tabelle1.spalte1 = tabelle2.spalte2;

Sie können diese Anfrage in eine Skriptdatei schreiben und deren Eingabe an den Kommandozeilen-Interpreter mysql leiten und von dort die Ausgabe zurück an eine zweite Instanz des Interpreters:

prompt> mysql --skip-column-names meine_db < mein_skript.sql | mysql meine_db

MySQL 4.0 unterstützt das Löschen aus mehreren Tabellen (multi-table deletes), was benutzt werden kann, um effizient Zeilen zu löschen, basierend auf den Informationen aus einer Tabelle oder sogar aus mehreren Tabellen zur gleichen Zeit.

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.

INSERT INTO tabelle_temp2 (fldID) SELECT tabelle_temp1.fldOrder_ID FROM tabelle_temp1 WHERE
tabelle_temp1.fldOrder_ID > 100;

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

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

Beachten Sie, dass Fremdschlüssel in SQL nicht dazu benutzt werden, um Tabellen zu verknüpfen, sondern hauptsächlich, um die referentielle Integrität zu überprüfen (Fremdschlüssel-Restriktionen). Wenn Sie durch ein SELECT-Statement Ergebnisse aus mehreren Tabellen erhalten wollen, tun Sie dies, indem Sie Tabellen verknüpfen (Join):

SELECT * von tabelle1,tabelle2 where tabelle1.id = tabelle2.id;

See section 7.4.1.1 JOIN-Syntax. See section 4.5.6 Wie Fremdschlüssel (Foreign Keys) verwendet werden.

Die FOREIGN KEY-Syntax in MySQL existiert nur aus Kompatibilitätsgründen mit den CREATE TABLE-Kommandos anderer Hersteller; sie tut nichts. Die FOREIGN KEY-Syntax ohne ON DELETE ... wird hauptsächlich für Dokumentationszwecke benutzt. Einige ODBC-Applikationen benutzen dies vielleicht, um automatische WHERE-Klauseln zu erzeugen, aber das läßt sich üblicherweise leicht überschreiben. FOREIGN KEY wird manchmal als Restriktionsprüfung benutzt, aber eine solche Überprüfung ist in der Praxis nicht notwendig, wenn Zeilen in Tabellen in der richtigen Reihenfolge eingefügt werden. MySQL unterstützt diese Klauseln nur, weil manche Applikationen verlangen, dass sie existieren (egal ob sie funktionieren oder nicht).

In MySQL 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.

In naher Zukunft werden wir die FOREIGN KEY-Implementation erweitern, so dass zumindest die Information in der Datei, die die Tabelle spezifiziert, gespeichert wird und somit durch mysqldump und ODBC abgefragt werden kann. Zu einem späteren Zeitpunkt werden wir Fremdschlüssel-Restriktionen für Applikationen implementieren, die nicht leicht durch entsprechendes Programmieren umgangen werden können.

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:

Nachteile:

2.7.4.7 Sichten (Views)

MySQL unterstützt noch keine Sichten, aber wir planen, diese in Version 4.1 zu implementieren.

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 werden, wo der Applikationsprogrammierer volle Kontrolle über die Datenbankbenutzung hat, sehen die meisten unserer Benutzer Sichten als nicht sehr wichtig an. (Zumindest war niemand interessiert genug, um die Implementation von Sichten zu finanzieren.)

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:

UPDATE tabelle_name SET kredit=kredit-!zahlung!

Was, glauben Sie, passiert, wenn der Wert von zahlung negativ wird?

Weil 1--1 in SQL zulässig ist, sind wir der Meinung, dass es furchtbar ist, dass `--' den Anfang eines Kommentars bedeutet.

In MySQL ab Version 3.23 können Sie allerdings folgendes benutzen: 1-- Das ist ein Kommentar

Die folgenden Erörterungen treffen nur zu, wenn Sie eine MySQL-Version vor 3.23 laufen lassen:

Wenn Sie ein SQL-Programm in einer Textdatei haben, das `--'-Kommentare enthält, sollten Sie folgendes benutzen:

shell> replace " --" " #" < text-datei-mit-merkwuerigen-kommentaren.sql \
         | mysql datenbank

anstelle des üblichen:

shell> mysql datenbank < text-datei-mit-merkwuerdigen-kommentaren.sql

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

shell> replace " --" " #" -- text-datei-mit-merkwuerdigen-kommentaren.sql

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

shell> replace " #" " --" -- text-datei-mit-merkwuerdigen-kommentaren.sql

2.7.5 Bekannte Fehler und Design-Unzulänglichkeiten in MySQL

Die folgenden Probleme sind bekannt. Ihre Behebung hat eine sehr hohe Priorität:

Folgende Probleme sind bekannt und werden zu gegebener Zeit behoben:

Folgende bekannte Bugs gibt es in früheren Versionen von MySQL:

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

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

2.8.3 Dinge die irgendwann gemacht werden müssen

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

2.9 MySQL im Vergleich mit anderen Datenbanken

Dieser Abschnitt vergleicht MySQL mit anderen populären Datenbanken.

Dieser Abschnitt wurde von den MySQL-Entwicklern geschrieben. Das sollte man beim Lesen im Hinterkopf behalten. In diesem Abschnitt sind - soweit uns bekannt - keine sachlichen Fehler enthalten. Wenn Sie etwas finden, was Sie als sachlichen Fehler erachten, kontaktieren Sie uns bitte unter docs@mysql.com.

Eine Liste aller unterstützten Limits, Funktionen und Typen finden Sie auf der crash-me-Webseite auf http://www.mysql.com/information/crash-me.php.

2.9.1 MySQL im Vergleich mit mSQL

Performance
Um einen echten Geschwindigkeitsvergleich zu sehen, schauen Sie bitte in der wachsenden Liste der MySQL-Benchmarks nach. See section 6.1.4 Die MySQL-Benchmark-Suite. Weil es keinen Overhead für die Erzeugung von Threads besitzt, einen kleineren Parser, weniger Features und einfache Sicherheitsmechanismen, sollte mSQL in folgenden Punkten schneller sein: Weil diese Operationen so einfach sind, ist es schwer, hier besser zu sein, wenn man beim Starten einen größeren Overhead hat. Nachdem die Verbindung erst einmal aufgebaut ist, sollte MySQL wesentlich bessere Leistungsdaten bringen. Andererseits ist MySQL sehr viel schneller als mSQL (und den meisten anderen SQL-Implementationen) bei Folgendem:
SQL-Features
Effiziente Ausnutzung von Speicherplatz
Das heißt, wie klein können Sie Ihre Tabellen machen? MySQL hat sehr präzise Typen, deshalb können Sie Tabellen erzeugen, die sehr wenig Platz brauchen. Ein Beispiel für einen nützlichen MySQL-Datentyp ist MEDIUMINT, der 3 Bytes lang ist. Wenn Sie 100 Millionen Datensätze haben, ist es schon von Wichtigkeit, auch nur ein Byte pro Datensatz zu sparen. mSQL2 hat eine begrenztere Anzahl von Spaltentypen, daher ist es schwieriger, kleine Tabellen zu erhalten.
Stabilität
Dieser Punkt ist schwieriger objektiv zu beurteilen. Eine Erörterung der Stabilität von MySQL finden Sie hier: section 2.2.2 Wie stabil ist MySQL?. Wir haben keine Erfahrungen mit der Stabilität von mSQL, daher können wir nichts darüber sagen.
Preis
Ein weiterer wichtiger Punkt ist die Lizenz. MySQL hat eine flexiblere Lizenz als mSQL und kostet auch weniger als mSQL. Welches Produkt auch immer Sie verwenden, ziehen Sie bitte zumindestens in Betracht, für eine Lizenz oder E-Mail-Support zu zahlen. (Sie müssen natürlich notwendigerweise eine Lizenz erwerben, wenn Sie MySQL in ein Produkt einbeziehen, das Sie verkaufen.)
Perl-Schnittstellen
MySQL hat prinzipiell dieselben Schnittstelle zu Perl wie mSQL, mit einigen zusätzlichen Features.
JDBC (Java)
MySQL hat aktuell eine große Anzahl von JDBC-Treibern: Der empfohlene Treiber ist der mm-Treiber. Der Resin-Treiber mag auch gut sein (zumindest sehen die Benchmarks gut aus), aber wir haben über diesen Treiber noch nicht allzu viele Informationen erhalten. Wir wissen, dass mSQL einen JDBC-Treiber hat, aber wir haben zu wenig Erfahrung damit, um ihn in einen Vergleich einzubeziehen.
Entwicklungsgeschwindigkeit
MySQL hat ein sehr kleines Entwicklerteam, aber wir arbeiten schon lange mit C und C++ und sind daher sehr schnell. Weil Threads, Funktionen, GROUP BY usw. noch nicht in mSQL implementiert sind, hat es eine Menge aufzuholen. Um das in den richtigen Blickwinkel zu rücken, können Sie sich die mSQL `HISTORY'-Datei des letzten Jahres ansehen und sie mit dem News-Abschnitt des MySQL Referenzhandbuchs vergleichen (see section D MySQL-Änderungsverlauf (Change History)). Es ist ziemlich offensichtlich, welches System sich schneller entwickelt hat.
Utilities
Sowohl mSQL als auch MySQL haben viele interessante von Dritten entwickelte Werkzeuge. Weil es sehr einfach ist, aufwärts zu portieren (von mSQL zu MySQL), sind fast alle interessanten Applikationen, die für mSQL verfügbar sind, auch für MySQL erhältlich. MySQL liefert ein einfaches msql2mysql-Programm mit, das Unterschiede in der Schreibweise zwischen mSQL und MySQL für die meistbenutzten C-API-Funktionen bereinigt. Es ändert zum Beispiel Instanzen von msqlConnect() zu mysql_connect(). Ein Client-Programm von mSQL zu MySQL zu konvertieren, erfordert meist nur geringe Anstrengung.

2.9.1.1 Wie man mSQL-Werkzeuge für MySQL konvertiert

Nach unserer Erfahrung nimmt es wenig Zeit in Anspruch, Werkzeuge wie msql-tcl und msqljava zu konvertieren, die die mSQL-C-API benutzen, damit sie mit der MySQL-C-API funktionieren.

Die Konvertierungsprozedur läuft wie folgt:

  1. Lassen Sie das Shell-Skript msql2mysql über den Quelltext laufen. Das erfordert das replace-Programm, das mit MySQL ausgeliefert wird.
  2. Kompilieren.
  3. Alle Kompilierfehler beheben.

Die Unterschiede zwischen der mSQL-C-API und der MySQL-C-API sind:

2.9.1.2 Wie sich mSQL- und MySQL-Client/Server-Kommunikationsprotokolle unterscheiden

Es gibt genug Unterschiede, so dass es unmöglich ist (oder zumindest nicht leicht), beide zu unterstützen.

Die signifikantesten Protokollunterschiede zwischen MySQL und mSQL sind folgende:

2.9.1.3 Wie sich die mSQL 2.0 SQL-Syntax von MySQL unterscheidet

Spaltentypen

MySQL hat folgende zusätzliche Typen (unter anderem; see section 7.5.3 CREATE TABLE-Syntax):
MySQL unterstützt folgende zusätzliche Typ-Attribute:
mSQL2
mSQL-Spaltentypen korrespondieren mit den unten dargestellten MySQL-Typen:
mSQL Typ Korrespondierender MySQL-Typ
CHAR(len) CHAR(len)
TEXT(len) TEXT(len). len ist die maximale Länge. Und LIKE funktioniert.
INT INT. Mit vielen weiteren Optionen!
REAL REAL. Or FLOAT. Beide 4- und 8-Byte-Versionen sind verfügbar.
UINT INT UNSIGNED
DATE DATE. Benutzt ANSI-SQL-Format statt mSQL's eigenem Format.
TIME TIME
MONEY DECIMAL(12,2). Ein Festkomma-Wert mit zwei Dezimalstellen.

Index-Erzeugung

MySQL
Indizes können bei der Erzeugung der Tabelle mit dem CREATE TABLE-Statement festgelegt werden.
mSQL
Indexe müssen erzeugt werden, nachdem die Tabelle erzeugt wurde, mit einem separaten CREATE INDEX-Statements.

Einfügen eines eindeutigen Identifikators (Unique Identifier) in eine Tabelle

MySQL
Benutzen Sie AUTO_INCREMENT als Spaltentyp-Spezifizierer. See section 9.4.3.126 mysql_insert_id().
mSQL
Erzeugen Sie eine SEQUENCE auf eine Tabelle und wählen Sie die _seq-Spalte.

Wie man einen eindeutigen Identifikator (Unique Identifier) für eine Zeile erhält

MySQL
Fügen Sie der Tabelle einen PRIMARY KEY oder UNIQUE-Schlüssel hinzu und benutzen Sie diesen. Neu ab Version 3.23.11: Wenn der PRIMARY- oder UNIQUE-Schlüssel nur aus einer Spalte besteht und diese vom Typ Ganzzahl (Integer) ist, können Sie auf diese auch mit _rowid verweisen.
mSQL
Benutzen Sie die _rowid-Spalte. Beachten Sie, dass sich _rowid im Zeitverlauf möglicherweise ändert, abhängig von vielen Faktoren.

Wie man die Zeit erhält, zu der eine Spalte zuletzt geändert wurde

MySQL
Fügen Sie der Tabelle eine TIMESTAMP-Spalte hinzu. Diese Spalte wird automatisch auf das aktuelle Datum und die aktuelle Zeit gesetzt, und zwar bei INSERT- und UPDATE-Statements, es sein denn, der Spalte wird explizit ein Wert zugewiesen, auch der NULL-Wert.
mSQL
Benutzen Sie die _timestamp-Spalte .

NULL-Wert-Vergleiche

MySQL
MySQL folgt ANSI-SQL, daher wird ein Vergleich mit NULL immer zu NULL ausgewertet.
mSQL
In mSQL ist NULL = NULL TRUE. Sie müssen =NULL zu IS NULL und <>NULL zu IS NOT NULL, wenn Sie alten Code von mSQL zu MySQL portieren.

Zeichenketten-Vergleich

MySQL
Normalerweise werden Zeichenketten-Vergleiche so durchgeführt, dass sie unabhängig von der verwendeten Groß-/Kleinschreibung laufen, wobei die Sortierreihenfolge vom aktuell verwendeten Zeichensatz abhängt (ISO-8859-1 Latin1 als Vorgabewert). Wenn Sie das nicht wollen, deklarieren Sie Ihre Spalten mit dem BINARY-Attribut, was bewirkt, dass Vergleiche nach der ASCII-Reihenfolge durchgeführt werden, wobei der ASCII-Zeichensatz gilt, den der MySQL-Server-Host verwendet.
mSQL
Alle Zeichenketten-Vergleiche werden so durchgeführt, dass sie abhängig von der verwendeten Groß-/Kleinschreibung laufen. Die Sortierung erfolgt in ASCII-Reihenfolge.

Suche, die unabhängig von Groß-/Kleinschreibung läuft

MySQL
LIKE ist ein Operator, der abhängig oder unabhängig von der Groß-/Kleinschreibung läuft, was davon abhängt, welche Spalten verwendet werden. Wenn möglich, benutzt MySQL Indexe, wenn das LIKE-Argument nicht mit einem Platzhalterzeichen (Wildcard) beginnt.
mSQL
Benutzt CLIKE.

Handhabung von Leerzeichen am Ende

MySQL
Entfernt alle Leerzeichen am Ende von CHAR- und VARCHAR-Spalten. Benutzen Sie eine TEXT-Spalte, wenn dieses Verhalten unerwünscht ist.
mSQL
Behält Leerzeichen am Ende bei.

WHERE-Klauseln

MySQL
MySQL priorisiert alles korrekt (AND wird vor OR ausgewertet). Um mSQL-Verhalten in MySQL zu erreichen, benutzen Sie Klammern (wie im unten stehenden Beispiel gezeigt).
mSQL
Wertet alles von links nach rechts aus. Das bedeutet, dass einige logische Berechnungen mit mehr als drei Argumenten überhaupt nicht ausgedrückt werden können. Das heißt auch, dass Sie einige Anfragen ändern müssen, wenn Sie auf MySQL umsteigen. Das einfachste ist, Klammern hinzuzufügen. Nehmen wir an, Sie haben die folgende mSQL-Anfrage:
mysql> SELECT * FROM tabelle WHERE a=1 AND b=2 OR a=3 AND b=4;
Damit MySQL dies auf dieselbe Art auswertet wie mSQL, müssen Sie Klammern hinzufügen:
mysql> SELECT * FROM tabelle WHERE (a=1 AND (b=2 OR (a=3 AND (b=4))));

Zugriffskontrolle

MySQL
Hat Tabellen, in denen Berechtigungsoptionen pro Benutzer, Host, und Datenbank gespeichert werden. See section 5.2.5 Wie das Berechtigungssystem funktioniert.
mSQL
Hat eine Datei `mSQL.acl', in der Sie Lese-/Schreibrechte für Benutzer gewähren können.

2.9.2 MySQL im Vergleich mit PostgreSQL

Wenn Sie das Folgende lesen, beachten Sie bitte, dass sich beide Produkte stetig entwickeln. Wir bei MySQL AB und die PostgreSQL-Entwickler geben sich alle Mühe, unsere jeweilige Datenbank so gut wie möglich zu machen. Daher sind es beide Produkte wert bei der Wahl einer kommerziellen Datenbank ernsthaft in Betracht gezogen zu werden.

Der folgende Vergleich wurde von uns bei MySQL AB durchgeführt. Wir haben uns bemüht, so akkurat und fair wie möglich zu sein. Da wir aber keine vollständige Kenntnis aller PostgreSQL-Features haben, während wir MySQL sehr genau kennen, haben wir vielleicht ein paar Dinge falsch verstanden. Wir werden das jedenfalls korrigieren, wenn es uns zu Ohren kommt.

Zunächst wollen wir feststellen, dass sowohl PostgreSQL als auch MySQL weit verbreitete Produkte sind, die aber unterschiedliche Entwurfsziele haben, auch wenn beide sich bemühen, ANSI-SQL-kompatibel zu sein. Das bedeutet, dass MySQL für einige Applikationen besser geeignet ist, PostgreSQL für andere. Wenn Sie überlegen, welche Datenbank Sie wählen sollen, sollten Sie zunächst prüfen, ob die Features der Datenbank für Ihre Applikation zufrieden stellend sind. Wenn Sie satte Geschwindigkeit brauchen, wird Ihre Wahl wahrscheinlich auf MySQL fallen. Wenn Sie einige der speziellen Merkmale brauchen, die nur PostgreSQL anbieten kann, sollten Sie PostgreSQL benutzen.

2.9.2.1 Entwicklungsstragien von MySQL und PostgreSQL

Wenn wir MySQL Dinge hinzufügen, ist es für uns eine Sache der Ehre, eine optimale, definitive Lösungen zu schaffen. Der Code sollte so gut sein, dass wir keine Notwendigkeit erkennen, ihn in der absehbaren Zukunft zu ändern. Wir wollen auch nicht Geschwindigkeit für Features opfern, sondern sind aufs Äußerste bestrebt, eine Lösung zu finden, die maximalen Durchsatz bietet. Das bedeutet, dass die Entwicklung ein bisschen länger dauert, aber die Endergebnisse sind es wert. Diese Art von Entwicklung ist nur möglich, weil der gesamte Server-Code nur von wenigen Leuten geprüft wird (aktuell zwei), bevor er in den MySQL-Server aufgenommen wird.

Wir bei MySQL AB halten viel von häufigen Releases, um in der Lage zu sein, neue Features schnell an unsere Benutzer heraus zu geben. Deshalb bringen wir etwa alle drei Wochen ein kleines Release heraus und einen größeren Zweig (Branch) einmal im Jahr. Alle Releases werden gründlich mit unseren Testwerkzeugen auf vielen verschiedenen Plattformen getestet.

PostgreSQL basiert auf einem Kern (Kernel), zu dem viele Leute etwas beigesteuert haben. Bei diesem Vorgehen ist es sinnvoll, dem Hinzufügen neuer Features Priorität einzuräumen, statt sie optimal zu implementieren, denn man kann immer noch später Dinge optimieren, wenn sich die Notwendigkeit hierfür ergibt.

Ein weiterer großer Unterschied zwischen MySQL und PostgreSQL besteht darin, dass praktisch der gesamte Code des MySQL-Servers von Entwicklern kodiert wurde, die bei MySQL AB angestellt sind und die immer noch am Server-Code arbeiten. Ausnahmen bilden die Transaktions-Engines und die Regexp-Bibliothek.

Das steht in scharfem Kontrast zum PostgreSQL-Code, wo der größte Teil des Codes von einer großen Gruppe von Leuten mit unterschiedlichem Hintergrund kodiert wird. Erst kürzlich gaben die PostgreSQL-Entwickler bekannt, dass ihre aktuelle Entwicklergruppe endlich Zeit gefunden hat, einen Blick auf all den Code der aktuellen PostgreSQL-Version zu werfen.

Beide der genannten Entwicklungsmethoden hat Ihre Vorzüge und Nachteile. Wir hier bei MySQL AB sind natürlich der Meinung, dass unser Modell besser ist, weil unser Modell bessere Konsistenz gewährleistet sowie mehr optimalen und damit wiederverwendbaren Code und deshalb nach unserer Meinung weniger Bugs. Weil wir die Autoren des MySQL-Server-Codes sind, sind wir besser im Stande, neue Features und Releases zu koordinieren.

2.9.2.2 Feature-Vergleich von MySQL und PostgreSQL

Auf der Seite crash-me finden Sie eine Liste der Datenbank-Konstrukte und -Beschränkungen, die man automatisch mit einem Programm entdecken kann. Beachten Sie jedoch, dass sich etliche numerische Beschränkungen mit Start-Optionen der jeweiligen Datenbank ändern lassen. Die genannte Seite ist jedoch äußerst nützlich, wenn Sie sicher stellen wollen, dass Ihre Applikationen mit vielen unterschiedlichen Datenbanken funktionieren, oder wenn Sie Ihre Applikation von einer Datenbank zu einer anderen konvertieren wollen.

MySQL bietet folgende Vorzüge gegenüber PostgreSQL:

Nachteile von MySQL im Vergleich zu PostgreSQL:

PostgreSQL hat momentan folgende Vorteile gegenüber MySQL:

Weil wir die Pläne (Roadmap) von MySQL kennen, haben wir in der folgenden Tabelle die Versionsnummern der jeweiligen MySQL-Version untergebracht, die das entsprechende Feature unterstützen wird. Leider konnten wir das nicht für frühere Vergleiche machen, denn wir kennen nicht kennen nicht die Pläne (Roadmap) von PostgreSQL.

Feature MySQL version
Subselects 4.1
Fremdschlüssel 4.0 und 4.1
Sichten (Views) 4.2
Gespeicherte Prozeduren 4.1
Erweiterbares Typ-System Nicht geplant
Unions 4.0
Full Join 4.0 oder 4.1
Trigger 4.1
Constrainst 4.1
Cursor 4.1 oder 4.2
Erweiterbare Indextypen wie R-Trees R-trees sind geplant für 4.2
Vererbte (Inherited) Tabellen Nicht geplant

Andere Gründe, PostgreSQL zu benutzen:

Nachteile von PostgreSQL im Vergleich zu MySQL:

Eine vollständige Aufstellung der Nachteile finden Sie in der ersten Tabelle dieses Abschnitts.

2.9.2.3 Benchmark-Vergleiche von MySQL und PostgreSQL

Der einzige Open-Source-Benchmark-Test, den wir kennen, der benutzt werden kann, um MySQL und PostgreSQL (und andere Datenbanken) miteinander zu vergleichen, ist unser eigener. Man findet ihn auf http://www.mysql.com/information/benchmarks.html.

Wir haben mehrfach bei den PostgreSQL-Entwicklern und bei einigen PostgreSQL-Benutzer nachgefragt, ob sie bereit wären, uns zu helfen, diesen Benchmark-Test zu erweitern, um ihn zu dem definitiven Benchmark-Test für Datenbanken zu machen, haben aber leider keinerlei Rückmeldung erhalten.

Wir, die MySQL-Entwickler, haben deshalb viele Stunden damit verbracht, für den Benchmark-Test maximale Performance aus PostgreSQL heraus zu bekommen, aber da wir mit PostgreSQL nicht sehr weitgehend vertraut sind, sind wir sicher, dass wir einige Dinge versäumt haben. Auf der Benchmark-Seite haben wir genau dokumentiert, wie wir den Benchmark-Test durchgeführt haben, deshalb sollte es für jeden einfach sein, ihn zu wiederholen und unsere Ergebnisse zu bestätigen.

Die Benchmarks werden üblicherweise mit und ohne die --fast-Option durchgeführt. Wenn wir sie mit --fast durchführen, versuchen wir, jeden Trick zu nutzen, den der Server benutzt, um den Code so schnell wie möglich auszuführen. Die Idee dahinter ist, dass der Server zeigen sollte, wie er mit Vorgabeeinstellungen läuft und --fast sollte zeigen, wie der Server läuft, wenn der Applikationsentwickler Erweiterungen im Server nutzt, um seine Applikation schneller laufen zu lassen.

Wenn wir PostgreSQL mit der --fast-Option laufen lassen, machen wir ein VACUUM() nach jedem größeren Tabellen-UPDATE und DROP TABLE, um die Datenbank in beste Verfassung für die folgenden SELECTs zu bringen. Die Zeit für VACUUM() wird separat gemessen.

PostgreSQL 7.1.1 konnten wir jedoch nicht mit der Option --fast laufen lassen, weil der Postmaster (der PostgreSQL Daemon) während eines INSERT-Tests starb und die Datenbank so beschädigt war, dass es unmöglich war, den Postmaster neu zu starten. Nachdem dies zweimal geschehen war, entschieden wir uns, den Test mit --fast bis zum nächsten PostgreSQL-Release zu verschieben. Die Details zur Maschine, die wir für den Benchmark benutzten, stehen auf der Benchmark-Seite.

Bevor wir uns den anderen Benchmarks, die wir kennen, zuwenden, möchten wir ein paar Hintergrundinformationen zu Benchmarks geben:

Es ist sehr einfach, einen Test zu schreiben, der zeigt, dass JEDE BELIEBIGE Datenbank die beste der Welt ist, indem man den Test einfach auf etwas beschränkt, was diese Datenbank sehr gut kann und nichts anderes testet, was die Datenbank nicht gut kann. Wenn man dann noch das Ergebnis mittels einer einzigen Zahl veröffentlicht, macht das die Dinge sogar noch einfacher.

Das wäre, als ob wir die Geschwindigkeit von MySQL gegenüber PostgreSQL anhand der Messzeit-Zusammenfassung der MySQL-Benchmarks auf unserer Webseite vergleichen würden. Auf dieser Basis wäre MySQL mehr als 40 Mal schneller als PostgreSQL, was natürlich nicht stimmt. Wir könnten die Sache sogar noch verschlimmern, indem wir nur etwas testen, worin PostgreSQL die schlechtesten Leistungsdaten bringt und geltend machen, dass MySQL mehr als 2000 Mal schneller ist als PostgreSQL.

Tatsache ist, dass MySQL eine Menge Optimierungen vornimmt, die PostgreSQL nicht vornimmt. Das ist natürlich auch umgekehrt so. Ein SQL-Optimierer ist eine sehr komplexe Sache, und ein Unternehmen könnte Jahre damit zubringen, nur den Optimierer schneller und schneller zu machen.

Wenn Sie sich die Ergebnisse der Benchmarks ansehen, sollten Sie nach Dingen Ausschau halten, die Sie in Ihrer Applikation durchführen, und dann nur diese Ergebnisse benutzen, um zu entscheiden, welche Datenbank wohl am besten für Ihre Applikation geeignet ist. Die Benchmark-Ergebnisse zeigen ausserdem auf, worin eine bestimmte Datenbank nicht gut ist, was Ihnen eine Ahnung davon geben sollte, welche Dinge Sie am besten vermeiden und was Sie auf andere Weise machen sollten.

Wir kennen zwei Benchmark-Tests, die behaupten, dass PostgreSQL bessere Leistungsdaten bringt als MySQL. Beide waren Mehrbenutzer-Tests, ein Test, den zu schreiben wir bei MySQL AB nie die Zeit hatten, hauptsächlich, weil es eine wirklich große Aufgabe ist, wenn man will, dass der Test fair zu allen Datenbanken ist.

Einer der Tests ist derjenige, für den Great Bridge bezahlt hat, und über den Sie hier lesen können: http://www.greatbridge.com/about/press.php?content_id=4.

Es ist wahrscheinlich der schlechteste Benchmark-Test, den wir jemals gesehen haben. Er war nicht nur so eingestellt, dass er das testete, was PostgreSQL absolut am besten kann, er war auch völlig unfair zu jeder anderen Datenbank, die in diesen Test einbezogen wurde.

ACHTUNG: Wir wissen, dass niemand der hauptsächlichen PostgreSQL-Entwickler die Art mochte, wie Great Bridge den Test durchgeführt hat, daher geben wir ihnen keinerlei Schuld dafür.

Dieser Benchmark wurde in einer Menge Postings und Newsgroups verurteilt, daher beschränken wir uns hier darauf, kurz einige Dinge zu wiederholen, die dabei nicht stimmten.

Tim Perdue, seit langer Zeit PostgreSQL-Fan und ein widerwilliger MySQL-Benutzer, hat einen Vergleich auf phpbuilder veröffentlicht.

Als wir von diesem Vergleich erfuhren, telefonierten wir mit Tim Perdue zu diesem Thema, weil es eine Menge merkwürdiger Dinge in seinen Ergebnissen gab. Er behauptete zum Beispiel, dass MySQL bei seinem Test ein Problem mit fünf Benutzern hatte, während wir wissen, dass es Benutzer mit ähnlichen Maschinen wie seine gibt, die MySQL mit 2000 simultanen Verbindungen betreiben, die 400 Anfragen pro Sekunde abarbeiten. (In diesem Fall war die Beschränkung durch die Web-Bandbreite gegeben, nicht durch die Datenbank.)

Es schien, als hätte er einen Linux-Kernel benutzt, der entweder Probleme mit vielen Threads hatte, wie ein Kernel vor Version 2.4, der ein Problem mit vielen Threads auf Mehrprozessor-Maschinen hat. Wir haben in diesem Handbuch dokumentiert, wie man das behebt, und Tim sollte sich dieses Problems bewusst sein.

Das andere mögliche Problem könnte eine alte glibc-Bibliothek gewesen sein, und dass Tim keine MySQL-Binärdistribution von unserer Site benutzte, die mit einer korrigierten glibc-Bibliothek gelinkt ist, sondern statt dessen eine eigene Version kompiliert hat. Bei jedem der genannten Fälle würden die Symptome genau die sein, die Tim gemessen hat.

Wir haben Tim gebeten, uns Zugang zu seinen Daten zu geben, damit wir den Benchmark-Test wiederholen könnten, sowie die MySQL-Version auf seiner Maschine zu prüfen, um herauszufinden, was falsch lief, und er hat versprochen, uns entsprechende Mitteilung zu geben. Das hat er bis heute nicht gemacht.

Aus diesem Grund können wir auch diesem Benchmark in keiner Weise vertrauen :(

Im Zeitverlauf haben sich die Dinge auch geändert und die genannten Benchmarks sind nicht mehr so relevant. MySQL hat mittlerweile eine Reihe unterschiedlicher Tabellen-Handler mit unterschiedlichen Verhältnissen zwischen Geschwindigkeit und Anzahl gleichzeitiger Zugriffe (Speed/Concurrency Tradeoffs). See section 8 MySQL-Tabellentypen. Es wäre interessant zu sehen, wie die obigen Tests mit den verschiedenen transaktionalen Tabellen von MySQL laufen würden. PostgreSQL hat natürlich auch neue Features erhalten, seit die Tests durchgeführt wurden. Weil die genannten Tests nicht öffentlich erhältlich sind, gibt es keine Möglichkeit für uns herauszufinden, wie die Datenbank heute mit denselben Tests laufen würde.

Fazit:

Der einzige Benchmark, der heutzutage existiert, den jeder herunter laden und laufen lassen kann, um MySQL und PostgreSQL zu vergleichen, ist der MySQL-Benchmark-Test. Wir hier bei MySQL sind der Überzeugung, dass Open-Source-Datenbanken mit Open-Source-Werkzeuge getestet werden sollten! Das ist die einzige Möglichkeit, um sicherzustellen, dass niemand Tests fährt, die nicht reproduzierbar sind, und diese dazu benutzt, um zu behaupten, dass eine Datenbank besser sei als die eine andere. Ohne die Fakten zu kennen ist es unmöglich, auf die Behauptungen des Testers einzugehen.

Eine Sache, die wir merkwürdig finden, ist, dass jeder Test, den wir zu PostgreSQL gesehen haben - und wo es unmöglich ist, diesen zu wiederholen -, behauptet, dass PostgreSQL in den meisten Hinsichten besser sei, während unsere Tests, die jeder reproduzieren kann, eindeutig das Gegenteil beweisen. Damit wollen wir nicht sagen, dass PostgreSQL nicht vieles sehr gut kann (das kann es!) oder dass es nicht unter bestimmten Umständen schneller ist als MySQL. Wir würden nur gern einen fairen Test sehen, der zeigt, worin PostgreSQL sehr gut ist, damit wir einen freundlichen Wettbewerb anzetteln können!

Mehr Informationen über unsere Benchmark-Suite finden Sie unter See section 6.1.4 Die MySQL-Benchmark-Suite.

Wir arbeiten an einer noch besseren Benchmark-Suite, die Mehrbenutzer-Tests beinhaltet sowie eine bessere Dokumentation dessen, was die einzelnen Tests genau tun und wie man weitere Tests zur Suite hinzufügt.


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