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
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..
Dieses Handbuch benutzt bestimmte typographische Konventionen:
constant
mysqladmin funktioniert, rufen
Sie den Befehl mit der --help Option auf.''
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}
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?.
Offiziell wird MySQL 'Mai Ess Ku Ell' ausgesprochen (nicht 'Mai Siekwel'). Wir vermeiden allerdings, Leute zu korrigieren, die Mai-Siekwel sagen.
Wir fingen ursprünglich mit der Intention an, den mSQL-Code zu
benutzen, um unsere eigenen Tabellen anzusprechen, wobei wir unsere
eigenen schnellen Low-Level-Routinen (ISAM) benutzten. Nach einigem
Testen gelangten wir allerdings zur Überzeugung, dass mSQL weder
schnell noch flexibel genug wäre, um unsere Anforderungen abzudecken.
Dies resultierte in einer neuen SQL-Schnittstelle zu unserer Datenbank,
allerdings mit fast derselben API-Schnittstelle, wie sie mSQL
benutzt. Diese API wurde gewählt, weil sie es erlaubte, Code von
Drittanbietern einfach zu portieren. Die Entstehung des Namens MySQL ist
nicht völlig geklärt. Unser Basis-Verzeichnis und eine große Anzahl
unserer Bibliotheken und Werkzeuge hatten immer schon das Präfix ``my''
während mehr als 10 Jahren. Wie auch immer, auch Montys Tochter (einige
Jahre jünger) heißt My. Welcher der beiden Umstände MySQL den Namen
gab, ist immer noch ein Rätsel, sogar für uns.
Die folgende Liste beschreibt einige wichtige Charakteristika von MySQL:
FLOAT,
DOUBLE, CHAR, VARCHAR, TEXT, BLOB,
DATE, TIME, DATETIME, TIMESTAMP,
YEAR, SET, und ENUM Typen.
See section 7.2 Spaltentypen.
SELECT- und
WHERE-Teilen von Anfragen. Beispiel:
mysql> SELECT CONCAT(vorname, " ", nachname) FROM tabellen_name
WHERE einkommen/dependents > 10000 AND age > 30;
GROUP BY und ORDER BY-
Klauseln. Unterstützung für Gruppierungsfunktionen (COUNT(),
COUNT(DISTINCT ...), AVG(), STD(), SUM(),
MAX() und MIN()).
LEFT OUTER JOIN und RIGHT OUTER JOIN mit
ANSI-SQL und ODBC-Syntax.
CHAR- oder VARCHAR-Felds
benutzen.
INSERT
benutzen, um eine Untermenge der Tabellenspalten mit Werten zu
bestücken. Diejenigen Spalten, die nicht explizit angesprochen werden,
werden auf ihre Vorgabewerte gesetzt.
myisamchk, ein sehr schnelles Dienstprogramm zur Überprüfung,
Optimierung und Reparatur von Tabellen. Die gesamte Funktionalität von
myisamchk steht auch über die SQL-Schnittstelle zur Verfügung.
See section 5 MySQL-Datenbankadministration.
DELETE, INSERT, REPLACE und UPDATE geben die
Anzahl der Zeilen zurück, die geändert wurden (bzw. betroffen sind). Es
ist statt dessen auch möglich, die Anzahl der übereinstimmenden Zeilen
zurückzugeben, indem beim Verbindungsstart zum Server ein entsprechendes
Flag gesetzt wird.
ABS zum Beispiel ist ein gültiger Spaltenname. Die einzige
Einschränkung besteht drin, dass in einem Funktionsaufruf keine
Leerzeichen zwischen Funktionsname und der öffnenden runden Klammer, die
diesem folgt `(', erlaubt ist. See section 7.1.6 Ist MySQL pingelig hinsichtlich reservierter Wörter?.
--help oder -? Option
aufgerufen werden, um Online-Hilfe zu erhalten.
SHOW-Befehl kann benutzt werden, um
Informationen über Datenbanken, Tabellen und Indexe zu erhalten. Der
EXPLAIN-Code kann benutzt werden um festzustellen, wie der
Optimierer eine Anfrage auflöst.
Dieser Abschnitt beschäftigt sich mit den Fragen ``Wie stabil ist MySQL?'' und ``Kann ich mich auf MySQL bei diesem Projekt verlassen?'' Wir werden versuchen, einige Dinge klar zu stellen und einige der wichtigeren Fragen zu beantworten, die offensichtlich viele Leute beschäftigen. Dieser Abschnitt wurde aus Informationen zusammen gestellt, die aus der Mailing-Liste gesammelt wurden (die sehr aktiv beim Berichten von Bugs ist).
Bei TcX funktioniert MySQL ohne jegliche Probleme in unseren Projekten seit Mitte 1996. Als MySQL einer breiteren Öffentlichkeit zugänglich gemacht wurde, fiel uns auf, dass es einige Teile von ``ungetestetem Code'' gab, die schnell von neuen Benutzern gefunden wurden, die Anfragen machten, die von unseren eigenen abwichen. Seitdem hat jedes neue Release weniger Portabilitätsprobleme als das vorhergehende (obwohl jedes viele neue Features hat).
Jedes Release von MySQL war benutzbar. Probleme gab es nur, wenn Benutzer anfingen, Code aus den ``Grauzonen'' zu benutzen. Natürlich wissen Benutzer von ausserhalb nicht, was diese Grauzonen sind, daher versucht dieser Abschnitt, die momentan bekannten aufzuzeigen. Die Beschreibungen hier beziehen sich auf Version 3.23 von MySQL. Alle bekannten und berichteten Bugs werden in der letzten Version behoben, mit Ausnahme der Bugs, die im Bugs-Abschnitt aufgelistet sind, was Dinge sind, die auf das Design zurückzuführen sind. See 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:
mysql, mysqladmin, mysqlshow,
mysqldump und mysqlimport.
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.
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).
SELECT-Statements werden üblicherweise in einem Zeit-Frame
ausgeführt, also sollte es kein mutex locking/thread juggling geben.
LOAD DATA ..., INSERT ... SELECT -- stabil
ALTER TABLE -- stabil
mysqlaccess -- stabil
GRANT -- stabil
InnoDB wurde im
MySQL 3.23-Baum stabil erklärt, ab Version 3.23.49.
InnoDB wird in großen hochbelasteten Produktionssystemen
eingesetzt.
MERGE-Tabellen ist noch nicht
sehr ausgetestet. Der restliche Teile des MERGE-Codes ist recht
gut getestet.
MySQL AB stellt E-Mail-Support für zahlende Kunden bereit, aber die MySQL-Mailingliste bietet üblicher Weise Antworten für die meisten Fragen. Bugs werden meist direkt mit einem Patch behoben; für schwerwiegende Bugs gibt es fast immer ein neues Release.
MySQL Version 3.22 hat eine Begrenzung auf 4G bei der Tabellengröße.
Mit dem neuen MyISAM in MySQL Version 3.23 wurde die maximale
Tabellengröße auf 8 Millionen Terabytes (2 ^ 63 bytes) hochgeschraubt.
Beachten Sie allerdings, dass Betriebssysteme ihre eigenen Dateigrößen- Beschränkungen haben. Hier sind einige Beispiele:
| Betriebssystem | Dateigrößen-Beschränkung |
| Linux-Intel 32 bit | 2G, 4G oder mehr, abhängig von der Linux-Version |
| Linux-Alpha | 8T (?) |
| Solaris 2.5.1 | 2G (möglich sind 4G mit Patch) |
| Solaris 2.6 | 4G |
| Solaris 2.7 Intel | 4G |
| Solaris 2.7 ULTRA-SPARC | 8T (?) |
Auf Linux 2.2 kann man größere Tabellen als 2G benutzen, wenn man den LFS-Patch für das ext2 Dateisystem benutzt. Auf Linux 2.4 existiert zusätzlich ein Patch für das ReiserFS, um Unterstützung für große Dateien zu erhalten.
Letztlich wird die Tabellengröße für MySQL normalerweise durch das Betriebssystem begrenzt.
Vorgabemäßig haben MySQL-Tabellen eine maximale Größe von etwa 4G. Sie
können die maximale Tabellengröße für eine Tabelle mit dem SHOW
TABLE STATUS-Befehl überprüfen oder mit myisamchk -dv
tabellen_name. See 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.
MySQL selbst hat keine Probleme mit der Jahr-2000-Konformität:
2069. Alle zweistelligen Jahresangaben werden
als Angaben zwischen 1970 und 2069, betrachtet, was
bedeutet, dass, wenn Sie 01 in einer Spalte speichern, MySQL dies
als 2001 behandelt.
YEAR
Jahre 0 und von 1901 bis 2155 in 1 Byte speichern
und sie mit 2 oder 4 Ziffern anzeigen.
Probleme können Sie bekommen, wenn Sie MySQL mit Applikationen benutzen,
die MySQL auf eine Art benutzen, die nicht Jahr-2000-sicher ist. Zum
Beispiel speichern oder ändern viele alte Applikationen Jahresangaben,
indem sie zweistellige Werte benutzen (was mehrdeutig ist), anstatt
vierstellige Werte zu nehmen. Dieses Problem kann durch Applikationen
verschlimmert werden, die Werte wie 00 oder 99 als Anzeiger
``fehlender'' Werte benutzen.
Leider sind diese Probleme möglicherweise schwer zu beheben, weil verschiedene Applikationen von unterschiedlichen Programmierern geschrieben sein können, von denen jeder einen anderen Satz von Konventionen und Funktionen benutzt haben kann, was die Handhabung von Datumsangaben betrifft.
Hier ist eine einfache Demonstration, die zeigt, dass MySQL keine Probleme mit Datumsangaben bis zum Jahr 2030 hat:
mysql> DROP TABLE IF EXISTS y2k;
Query OK, 0 rows affected (0.01 sec)
mysql> CREATE TABLE y2k (date date, date_time datetime, time_stamp timestamp);
Query OK, 0 rows affected (0.00 sec)
mysql> INSERT INTO y2k VALUES
-> ("1998-12-31","1998-12-31 23:59:59",19981231235959),
-> ("1999-01-01","1999-01-01 00:00:00",19990101000000),
-> ("1999-09-09","1999-09-09 23:59:59",19990909235959),
-> ("2000-01-01","2000-01-01 00:00:00",20000101000000),
-> ("2000-02-28","2000-02-28 00:00:00",20000228000000),
-> ("2000-02-29","2000-02-29 00:00:00",20000229000000),
-> ("2000-03-01","2000-03-01 00:00:00",20000301000000),
-> ("2000-12-31","2000-12-31 23:59:59",20001231235959),
-> ("2001-01-01","2001-01-01 00:00:00",20010101000000),
-> ("2004-12-31","2004-12-31 23:59:59",20041231235959),
-> ("2005-01-01","2005-01-01 00:00:00",20050101000000),
-> ("2030-01-01","2030-01-01 00:00:00",20300101000000),
-> ("2050-01-01","2050-01-01 00:00:00",20500101000000);
Query OK, 13 rows affected (0.01 sec)
Records: 13 Duplicates: 0 Warnings: 0
mysql> SELECT * FROM y2k;
+------------+---------------------+----------------+
| date | date_time | time_stamp |
+------------+---------------------+----------------+
| 1998-12-31 | 1998-12-31 23:59:59 | 19981231235959 |
| 1999-01-01 | 1999-01-01 00:00:00 | 19990101000000 |
| 1999-09-09 | 1999-09-09 23:59:59 | 19990909235959 |
| 2000-01-01 | 2000-01-01 00:00:00 | 20000101000000 |
| 2000-02-28 | 2000-02-28 00:00:00 | 20000228000000 |
| 2000-02-29 | 2000-02-29 00:00:00 | 20000229000000 |
| 2000-03-01 | 2000-03-01 00:00:00 | 20000301000000 |
| 2000-12-31 | 2000-12-31 23:59:59 | 20001231235959 |
| 2001-01-01 | 2001-01-01 00:00:00 | 20010101000000 |
| 2004-12-31 | 2004-12-31 23:59:59 | 20041231235959 |
| 2005-01-01 | 2005-01-01 00:00:00 | 20050101000000 |
| 2030-01-01 | 2030-01-01 00:00:00 | 20300101000000 |
| 2050-01-01 | 2050-01-01 00:00:00 | 00000000000000 |
+------------+---------------------+----------------+
13 rows in set (0.00 sec)
Das zeigt, dass die DATE- und DATETIME-Typen für zukünftige
Datumsangaben keine Probleme bereiten werden (sie handhaben Datumsangaben
bis zum Jahr 9999).
Der TIMESTAMP-Typ, der zur Speicherung der aktuellen Zeit benutzt
wird, hat nur einen Bereich bis zu 2030-01-01. TIMESTAMP hat
einen Bereich von 1970 bis 2030 auf 32-Bit-Maschinen
(vorzeichenbehafteter Wert). Auf 64-Bit-Maschinen handhabt dieser
Spaltentyp bis zu 2106 (vorzeichenloser Wert).
Obwohl MySQL Jahr-2000-kompatibel ist, sind Sie dafür verantwortlich, mehrdeutige Eingaben zu vermeiden. Siehe section 2.2.4 Jahr-2000-Konformität wegen der Regeln, die MySQL anwendet, wenn mehrdeutige Datumsangaben gemacht werden (Datumsangaben, die zweistellige Jahreswerte verwenden).
MySQL AB ist das Unternehmen der MySQL Gründer und Hauptentwickler.
MySQL AB wurde ursprünglich in Schweden von David Axmark, Allan Larsson
und Michael Monty Widenius gegründet.
Alle Entwickler des MySQL Servers sind Angestellte dieses Unternehmens. Wir sind eine virtuelle Firma mit Mitarbeitern, die über die ganze Welt verstreut in aller Herren Länder sitzen. Der Hauptteil unserer Kommunikation untereinander, mit unseren Anwendern, Unterstützern und Partnern wird über das Internet abgewickelt
Wir haben uns der Entwicklung und Verbreitung des MySQL Datenbankservers verschrieben. MySQL hält das Copyright der MySQL Quelltexte, des MySQL Logos und dieses Handbuchs.. See 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:
Eine der uns häufig gestellten Fragen ist: Wie kann man von etwas leben, das man kostenlos abgibt? Hier ist die Antwort: MySQL AB verdient Geld mit Support, Dienstleistungen, kommerziellen Lizenzen und Lizenzgebühren, das wir dazu verwenden, die Produktentwicklung zu finanzieren und die MySQL-Geschäftsfelder auszubauen.
Unser Unternehmen läuft seit der Gründung profitabel. Im Oktober 2001 akzeptierten wir eine Risikokapitalfinanzierung durch führende skandinavische Investoren und eine Handvoll Business-Angels. Die Investitionen werden genutzt, um unser Geschäftsmodell auf solide Füße zu stellen und eine Grundlage für nachhaltiges Wachstum zu schaffen.
MySQL AB gehört den Gründern und Haupt-Entwicklern der MySQL-Datenbank
und wird von ihnen betrieben. Die Entwickler fühlen sich verpflichtet,
Kunden und anderen Benutzern Support zu bieten, um mit deren
Bedürfnissen und Problemen in Kontakt zu bleiben. Unser gesamter Support
wird durch qualifizierte Entwickler geleistet. Wirklich schwierige
Fragen werden von Michael Monty Widenius beantwortet, der der
erste Entwickler des MySQL-Servers ist. See 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.
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.
MySQL AB und seine authorisierten Partner bieten Benutzern des MySQL-Servers und denen, die ihn in ihre Software einbetten wollen, Beratungsleistungen, weltweit.
Unsere Berater können Ihnen helfen, Ihre Datenbanken zu entwerfen und zu optimieren, effiziente Anfragen zu konstruieren, Ihre Plattform auf optimale Performance zu tunen, Migrationsprobleme zu lösen, Replikation aufzusetzen, robuste transaktionale Applikationen zu bauen und vieles mehr. Wir helfen auch Kunden dabei, den MySQL-Server für den Großflächigen Einsatz in ihre Produkte und Applikationen einzubauen.
Unsere Berater arbeiten in enger Kooperation mit unserem Entwicklungsteam, was die technische Qualität unserer Dienstleistungen sicherstellt. Beratungsaufgaben erstrecken sich von zweitägigen Power-Start-Sessions bis zu Projekten, die Wochen und Monate dauern. Unsere Kompetenz deckt nicht nur den MySQL-Server ab, sondern auch Programmier- und Skripting-Sprachen wie PHP, Perl und andere.
Wenn Sie an unseren Beratungsleistungen interessiert sind oder ein Consulting-Partner werden wollen, besuchen Sie bitte unsere Seite unter http://www.mysql.com/consulting/. Wenn Sie nur beschränkten Zugriff auf das Internet haben, setzen Sie sich bitte mit unserem Beratungspersonal unter consulting@mysql.com in Verbindung.
Die MySQL-Datenbank wird unter der GNU General Public License
veröffentlicht (GPL). Das bedeutet, dass die MySQL-Software
kostenlos unter der GPL benutzt werden darf. Wenn Sie nicht an die
GPL-Bedingungen gebunden sein wollen (was in der Folge bedeutet, dass
auch Ihre eigenen Applikationen GPL werden), können Sie eine
kommerzielle Lizenz für dasselbe Produkt unter
https://order.mysql.com/ erwerben.
Weil MySQL AB das Copyright am MySQL-Server besitzt, können wir eine
duale Lizensierung einsetzen, was heißt, dass dasselbe Produkt
sowohl unter der GPL als auch unter einer kommerziellen Lizenz
erhältlich ist. Das berührt in keiner Weise die Verpflichtung von MySQL
AB gegenüber Open Source. Wegen Details, wann eine kommerzielle
Lizenz erforderlich ist, sehen Sie bitte unter
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.
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.
Die MySQL-Website (http://www.mysql.com/) ist bei Entwicklern und Benutzern beliebt. Im Oktober 2001 bedienten wir 10 Millionen Seitenanfragen (PageViews). Unsere Besucher repräsentieren eine Gruppe, die Kaufentscheidungen und Empfehlungen sowohl für Software als auch für Hardware trifft. 12% unserer Besucher genehmigen Kaufentscheidungen, lediglich 9% sind überhaupt nicht an Kaufentscheidungen beteiligt. Mehr als 65% haben innerhalb des letzten halben Jahres online eingekauft, 70% planen, in den nächsten Monaten einzukaufen. Wenn Sie Interesse haben, Werbebanner auf unserer Website http://www.mysql.com/ zu schalten, setzen Sie sich bitte mit advertising@mysql.com in Kontakt.
Die MySQL Website (http://www.mysql.com/) enthält die neusten Informationen über MySQL und MySQL AB.
Für Presseservice und Anfragen aller Art, die in unseren Veröffentlichungen (http://www.mysql.com/news/) nicht behandelt werden, wenden Sie sich bitte an press@mysql.com.
Zeitnahe, präzise Antworten auf technische Fragen erhalten Sie, wenn Sie unter order einen unserer Support-Verträge abschließen. MySQL-Support wird von den MySQL-Entwicklern geleistet, weshalb der Standard extrem hoch ist.
Informationen über MySQL Trainig erhalten Sie unter http://www.mysql.com/training/. Wenn Sie einen eingeschränkten Internetzugang haben, kontaktieren Sie bitte unser Trainingspersonal unter training@mysql.com. See 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.
Dieser Abschnitt beschreibt die MySQL Support und Lizensierungsvereinbarungen
Wir versuchen, technischen Support in einem breiten und umfassenden Blickwinkel zu sehen. Fast jedes Problem im Zusammenhang mit MySQL-Software ist für uns wichtig, wenn es für Sie wichtig ist. Typischerweise suchen Kunden Hilfe dabei, wie man unterschiedliche Befehle und Dienstprogramme zum Funktionieren bringt, wie Performance-Flaschenhälse beseitigt werden können, wie man beschädigte Systeme repariert, wie sich Betriebssysteme oder Netzwerkkonfigurationen auf MySQL auswirken, wie man Datensicherung und Wiederherstellung optimal konfiguriert, wie man APIs benutzt usw. Unser Support deckt nur den MySQL-Server und unsere eigenen Dienstprogramme ab, nicht Produkte Dritter, die auf den MySQL-Server zugreifen, obwohl wir auch hierbei versuchen, zu helfen wo wir können.
Detaillierte Informationen über unsere unterschiedlichen Support-Optionen finden Sie auf https://order.mysql.com/, wo auch Support-Verträge online bestellt werden können. Wenn Sie nur beschränkten Zugriff auf das Internet haben, setzen Sie sich mit unserem Vertrieb unter sales@mysql.com in Verbindung.
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
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:
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.
getopt)-Bibliothek werden
von der ``GNU LIBRARY GENERAL PUBLIC LICENSE'' abgedeckt. See section I GNU LESSER GENERAL PUBLIC LICENSE.
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.
regexp-Bibliothek) werden
von einem Copyright in Berkeley-Art abgedeckt.
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.
Internet Service Provider (ISP) hosten oft MySQL-Server für ihre Kunden. Aufgrund der GPL-Lizenz ist hierfür keine Lizensierung erforderlich.
Auf der anderen Seite ermutigen wir Leute, ISPs zu benutzen, die MySQL-Support haben, und das wird ihnen Vertrauen geben, dass ihr ISP im Falle von Problemen mit ihrer MySQL-Installation helfen wird, das Problem zu lösen (in manchen Fällen mit der Hilfe des MySQL-Entwicklungsteams).
Alle ISPs, die auf dem neuesten Stand der Dinge bleiben wollen, sollten sich
in die announce-Mailing-Liste eintragen, um auf der Hut zu sein vor
schwerwiegenden Problemen, die für ihre MySQL-Installationen relevant sein
könnten.
Beachten Sie bitte, dass ein ISP ohne MySQL-Lizenz seinen Kunden zumindest Lesezugriff auf den Quelltext der MySQL-Installation geben sollte, damit die Kunden feststellen können, dass diese korrekt gepatcht ist.
Wenn Sie MySQL in Verbindung mit einem Webserver unter Unix betreiben, brauchen Sie nicht für eine Lizenz zu bezahlen.
Das gilt selbst dann, wenn Sie einen kommerziellen Webserver betreiben, der MySQL benutzt, weil Sie nicht selbst eine eingebettete MySQL-Version verkaufen. Dennoch bitten wir Sie, in einem solchen Fall MySQL-Support zu kaufen, weil MySQL Ihrem Unternehmen hilft.
Viele MySQL-Datenbankbenutzer wollen auf Ihren Websites, ihren Büchern
und Packungsprodukten das MySQL-AB-Delphin-Logo zeigen. Wir begrüßen
das und ermuntern dazu, weisen aber darauf hin, dass das Wort
MySQL und das MySQL-Delphin-Logo Schutzmarken von MySQL AB sind
und nur so benutzt werden dürfen, wie in unserer Schutzmarken-Richtlinie
unter http://www.mysql.com/company/trademark.html festgelegt.
Das MySQL-Delphin-Logo wurde von der finnischen Werbeagentur Priority im Jahr 2001 entworfen. Der Delphin wurde als passendes Symbol für die MySQL-Datenbank gewählt, weil er schlau, schnell und schlank ist und mühelos durch die Daten-Ozeane navigiert. Ausserdem mögen wir Delphine.
Das Original-MySQL-Logo darf nur von Repräsentanten von MySQL AB und von Personen benutzt werden, die eine schriftliche Erlaubnis hierfür haben.
Wir haben einen Satz spezieller Logos für vorbehaltliche Benutzung angelegt, die von unserer Website unter http://www.mysql.com/press/logos.html herunter geladen werden können und von Dritten auf ihren Websites ohne schriftliche Erlaubnis von MySQL AB benutzt werden dürfen. Der Gebrauch dieser Logos ist - wie der Name anzeigt - nicht völlig uneingeschränkt, sondern unterliegt unseren Schutzmarken-Richtlinien, die Sie auf unserer Website finden. Sie sollten diese Richtlinien lesen, wenn Sie planen, die Logos zu benutzen. Die Anforderungen sind im Wesentlichen:
Setzen Sie sich unter trademark@mysql.com mit uns in Verbindung, um wegen spezieller Arrangements anzufragen, die Ihren Bedürfnissen entsprechen.
In folgenden Fällen benötigen Sie eine schriftliche Erlaubnis von MySQL AB, bevor Sie die MySQL-Logos benutzen:
Aus rechtlichen und kommerziellen Gründen müssen wir die Benutzung der MySQL-Schutzmarken auf Produkten, Büchern usw. beobachten. Üblicherweise verlangen wir eine Gebühr für das Anzeigen von MySQL-AB-Logos auf kommerziellen Produkten, weil wir der Meinung sind, das es vertretbar ist, dass einige der Erlöse für die Weiterentwicklung der MySQL- Datenbank zurückfließen.
MySQL-Partnerschafts-Logos dürfen nur von Unternehmen und Personen benutzt werden, die eine schriftliche Partnerschaftsvereinbarung mit MySQL AB haben. Partnerschaften beinhalten eine Zertifizierung als MySQL-Trainer oder -Berater. Sehen Sie bitte unter section 2.3.1.5 Partnerprogramme nach.
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:
GNU Library General Public License-Lizenz. Der
mysql-Kommandozeilen-Client beinhaltet Code der
readline-Bibliothek, die unter GPL steht.
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.
MySQL in Druckmaterialien oderPrä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.
MySQL in Unternehmens- undProduktnamen
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.
Dateline: 16. Oktober 2001, Uppsala, Schweden
Lange durch MySQL AB angekündigt und lange von unseren Benutzern erwartet: Der MySQL-Server 4.0 ist jetzt in der Alpha-Version zum Herunterladen von http://www.mysql.com/ und unseren Mirrors verfügbar.
Die neuen Haupt-Features des MySQL-Servers 4.0 sind eng mit unserem bestehenden Geschäft und den Community-Nutzern verzahnt. Durch ihn wird die MySQL-Datenbank-Software als Lösung für geschäftskritische Schwerlast-Datenbanksysteme verbessert. Weitere neue Features zielen auf die Benutzer eingebetteter Datenbanken.
Das Erscheinen des MySQL-Servers 4.0 wird in mehreren Schritten erfolgen, wobei die erste Version 4.0.0 genannt wird und bereits die meisten neuen Features enthält. Zusätzliche Features werden in die Versionen 4.0.1, 4.0.2 usw. eingebaut, höchstwahrscheinlich innerhalb weniger Monate. MySQL 4.0 wird als Beta gekennzeichnet. In MySQL 4.1 werden dann weitere neue Features hinzugefügt. Es wird angestrebt, das Alpha-Release Anfang 2002 herauszubringen.
Es wird nicht empfohlen, Produktionssysteme auf den MySQL-Server 4.0 umzustellen, bis dieser in der Beta-Version veröffentlicht wird. Selbst das anfängliche Release hat unsere ausgiebigen Tests ohne jegliche Fehler durchlaufen, auf allen Plattformen, auf denen wir testen. Wegen der großen Zahl neuer Features empfehlen wir daher den MySQL-Server selbst in der Alpha-Version für Entwicklungsarbeiten, wobei in Betracht gezogen werden kann, dass der MySQL-Server 4.0 das Stadium "stabil" erreichen wird, bevor Applikationen hiermit veröffentlicht werden, die jetzt im Entwicklungsstadium sind.
libmysqld macht den MySQL-Server für einen erheblich ausgedehnten
Bereich von Applikationen geeignet. Wenn man die eingebettete MySQL-
Server-Bibliothek benutzt, kann man den MySQL-Server in
unterschiedlichste Applikationen und elektronische Geräte einbetten, bei
denen der Endbenutzer keinerlei Ahnung davon hat, dass ihnen eine
Datenbank unterlegt ist. Der eingebettete MySQL-Server ist ideal für
Benutzung hinter den Kulissen in Internet-Geräten, öffentlichen Kiosken,
schlüsselfertigen Hardware-/Software-Einheiten, Hochlast-Internet-
Servern oder Datenbanken, die auf CD-ROM vertrieben werden.
Viele Benutzer von eingebettetem MySQL können von der dualen Lizensierung der MySQL-Software profitieren. Neben der GPL-Lizenz sind auch kommerzielle Lizenzen für diejenigen verfügbar, die nicht an die GPL gebunden sein wollen. Die eingebettete MySQL-Bibliothek benutzt dieselbe Schnittstelle wie die normale Client-Bibliothek und ist daher angenehm und leicht zu benutzen. See section 9.4.9 libmysqld, die eingebettete MySQL-Server-Bibliothek.
INSERTs,
beim Suchen auf komprimierten Indexen, der Erzeugung von
FULLTEXT-Indexen oder auch bei COUNT(DISTINCT).
InnoDB wird jetzt als Feature des
standardmäßigen MySQL-Servers angeboten und enthält vollständige
Unterstützung für Transaktionen und Sperren auf
Zeilenebene.
Secure Sockets
Layer (SSL) benutzen, was ihn in die Lage versetzt, eine sichere
Datenübertragung zwischen einer MySQL-Datenbank und beispielsweise einer
Windows-Applikation ausserhalb der Firewall aufzubauen.
Migration von anderen Datenbanksystemen
zum MySQL-Server erleichtern, gehören TRUNCATE TABLE (wie in
Oracle) und IDENTITY a1s Synonym für automatisch hochgezählte
Schlüssel (wie in Sybase). viele Benutzer werden sich auch darüber
freuen, dass der MySQL-Server jetzt das UNION-Statement
unterstützt, ein lang erwartetes Standard-SQL-Feature.
DELETE-Statements. Durch das Hinzufügen von
Unterstützung für symbolisches Verknüpfen von MyISAM auf
Tabellenebene (und nicht nicht - wie bisher - auf Datenbankebene), sowie
durch das vorgabemäßige Anschalten der Verknüpfungen unter Windows
hoffen wir zeigen zu können, dass wir Verbesserungsvorschläge ernst
nehmen. Funktionen wie SQL_CALC_FOUND_ROWS und
FOUND_ROWS() ermöglichen herauszufinden, wie viele Zeilen eine
Anfrage ohne eine LIMIT-Klausel zurückgegeben hätte.
Für die kommenden Releases des MySQL-Servers 4.0 (4.0.1, 4.0.2 usw.) können Sie folgende Features erwarten, die noch in der Entwicklung sind:
absturzsichere Replikation beinhalten, die es bereits in Version
4.0.0 gibt, sowie den LOAD DATA FROM MASTER-Befehl, der bald das
Aufsetzen von Slaves automatisieren wird. online backup wird das
Hinzufügen eines neuen Replikations-Slaves erleichtern, ohne dass man
den Master herunterfahren muss, und es gibt auf Systemen mit vielen
Aktualisierungen nur geringe Geschwindigkeitseinbussen.
FULLTEXT)-Suche ermöglichen die FULLTEXT-Indexierung
großer Texte sowohl mit binärer wie auch mit natürlichsprachiger
Suchlogik. Benutzer können minimale Wortlängen anpassen und ihre
eigenen Stopp-Wort-Listen in jeder menschlichen Sprache festlegen,
wodurch gänzlich neue Applikationen ermöglicht werden, die auf dem
MySQL-Server aufbauen.
Schlüssel-Caches
profitieren.
MySQL-Befehlshilfe im Client
freuen.
Intern wird durch das neue .frm-Dateiformat für Tabellendefinitionen in
MySQL-Server 4.0 die Grundlage für neue Features in MySQL-Server 4.1
gelegt, beispielsweise verschachtelte Unterabfragen,
gespeicherte Prozeduren und Fremdschlüssel-
Integritätsregeln, die ganz oben auf der Wunschliste vieler unserer
Kunden stehen. Daneben werden auch einfachere Erweiterungen wie Multi-
Tabellen-UPDATE-Statements hinzugefügt.
Nach diesen Ergänzungen werden Kritiker des MySQL-Datenbankservers es noch schwerer haben, auf Schwächen des MySQL-Datenbank-Managementsystems hinzuweisen. MySQL, das seit langem für seine Stabilität, Geschwindigkeit und Einfachheit der Benutzung bekannt ist, wird dann den Anforderungen sehr anspruchsvoller Käufer genügen.
Die MySQL-Portale (http://www.mysql.com/portal/) auf unserer Website bieten ein breites Spektrum MySQL-bezogener Informationen und Links. Sie sind so aufgebaut, dass Sie leicht die Dinge finden, die Sie interessieren.
Sie können sich als Benutzer registrieren. In diesem Fall können Sie alle Dinge in den Portalen kommentieren und bewerten und auch selbst Dinge beisteuern. Bei der Registrierung können Sie auch angeben, ob und - wenn ja - welche Newsletter aus welchen Kategorien Sie beziehen wollen.
Einige der momentanen MySQL-Portal-Kategorien:
Dieser Abschnitt führt Sie in die MySQL-Mailing-Listen ein und zeigt einige Richtlinien und ihre Benutzung auf.
Um die MySQL-Haupt-Mailing-Liste zu abonnieren, schicken Sie eine Nachricht an die E-Mail-Adresse mysql-subscribe@lists.mysql.com.
Um sich aus der MySQL-Haupt-Mailing-Liste auszutragen, schicken Sie eine Nachricht an die E-Mail-Adresse mysql-unsubscribe@lists.mysql.com.
Von Bedeutung ist nur die Adresse, unter der Sie Ihre Nachrichten abschicken. Betreffzeile und Text der Nachricht werden ignoriert.
Wenn Ihre Antwortadresse nicht gültig ist, können Sie Ihre Adresse explizit
angeben. Fügen Sie einen Bindestrich zum Abonnement- oder
Abmelde-Kommando hinzu, gefolgt von Ihrer Adresse, wobei das
`@'-Zeichen in Ihrer Adresse durch `=' ersetzt wird. Um sich zum
Beispiel mit your_name@host.domain einzutragen, schicken Sie eine
Nachricht an mysql-subscribe-your_name=host.domain@lists.mysql.com.
Mails an mysql-subscribe@lists.mysql.com oder mysql-unsubscribe@lists.mysql.com werden automatisch vom ezmlm Mailing-Listen-Prozessor bearbeitet. Informationen über ezmlm sind auf The ezmlm Website verfügbar.
Um eine Nachricht an die Liste selbst zu schicken, schicken Sie eine Mail
an mysql@lists.mysql.com. Schicken aber bitte keine Mail an
mysql@lists.mysql.com, die das Abonnieren oder Austragen betrifft,
denn Mails an diese Adresse werden automatisch an tausende anderer Benutzer
verteilt.
Wenn Ihre lokale Site viele Abonnenten für mysql@lists.mysql.com
hat, sollten Sie evtl. eine lokale Mailing-Liste einrichten, so dass
Nachrichten, die von lists.mysql.com an Ihre Site gesandt werden, an
die lokale Liste verteilt werden. In solchen Fällen wenden Sie sich bitte
an Ihre Systemadministrator, um zur lokalen Mailing-Liste hinzugefügt oder
aus ihr gelöscht zu werden.
Wenn Sie wollen, dass der Traffic einer Mailing-Liste in eine separate
Mailbox Ihres E-Mail-Programms geleitet wird, setzen Sie einen Filter,
der auf die E-Mail-Header (Kopfdaten) reagiert. Sie können dazu entweder
den List-ID:- oder den Delivered-To:-Header benutzen, um die
Listennachrichten zu erkennen.
Die folgenden MySQL-Mailing-Listen existieren:
announce-subscribe@lists.mysql.com announce
mysql-subscribe@lists.mysql.com mysql
mysql-digest-subscribe@lists.mysql.com mysql-digest
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
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
bugs-Liste.
internals-subscribe@lists.mysql.com internals
internals-digest-subscribe@lists.mysql.com internals-digest
internals-Liste.
java-subscribe@lists.mysql.com java
java-digest-subscribe@lists.mysql.com java-digest
java-Liste.
win32-subscribe@lists.mysql.com win32
win32-digest-subscribe@lists.mysql.com win32-digest
win32-Liste.
myodbc-subscribe@lists.mysql.com myodbc
myodbc-digest-subscribe@lists.mysql.com myodbc-digest
myodbc-Liste.
plusplus-subscribe@lists.mysql.com plusplus
plusplus-digest-subscribe@lists.mysql.com plusplus-digest
plusplus-Liste.
msql-mysql-modules-subscribe@lists.mysql.com msql-mysql-modules
msql-mysql-modules-digest-subscribe@lists.mysql.com msql-mysql-modules-digest
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
subscribe mysql
your@email.address an diese Liste.
mysql-de-request@lists.4t2.com Eine deutsche Mailing-Liste
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.
subscribe mysql-br
your@email.address an diese Liste.
mysql-alta@elistas.net Eine spanische Mailing-Liste.
subscribe mysql
your@email.address an diese Liste.
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.
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:
mysqladmin version eingeben. mysqladmin findet
sich im `bin'-Verzeichnis unterhalb Ihres
MySQL-Installationsverzeichnisses.
uname -a ausführt.
mysqld abstürzt, sollten Sie auch die Anfrage (Query)
mitteilen, die mysqld zum Absturz brachte. Gewöhnlich können Sie das
herausfinden, indem Sie mysqld mit angeschaltetem Logging laufen
lassen. See section E.1.5 Log-Dateien benutzen, um Gründe für Fehler in mysqld zu finden.
mysqldump --no-data db_name tbl_name1 tbl_name2
... ein. Das ist sehr leicht zu bewerkstelligen und eine sehr hilfreiche
Möglichkeit, Informationen über jegliche Tabelle in einer Datenbank zu
erhalten, die uns hilft, eine Situation herzustellen, die mit derjenigen
übereinstimmt, die Sie haben.
SELECT-Statements, sollten Sie immer die Ausgabe von
EXPLAIN SELECT ... einschließen, und zumindest die Anzahl der
Zeilen, die das SELECT-Statement produziert. Je mehr Informationen
Sie uns über Ihre Situation geben, desto wahrscheinlicher ist es, dass
Ihnen jemand helfen kann! Das folgende Beispiel ist ein sehr gutes Beispiel
eines Bug-Berichts (es sollte natürlich mit dem mysqlbug-Skript
berichtet werden):
Beispiel unter Benutzung des mysql-Kommandozeilen-Werkzeugs (achten Sie
auf die Benutzung des \G-Statement-Begrenzers für Statements, deren
Ausgabebreite ansonsten die von 80-Zeilen-Ausgabegeräten überschreiten
würde):
mysql> SHOW VARIABLES;
mysql> SHOW COLUMNS FROM ...\G
<Ausgabe von SHOW COLUMNS>
mysql> EXPLAIN SELECT ...\G
<Ausgabe von EXPLAIN>
mysql> FLUSH STATUS;
mysql> SELECT ...;
<Eine Kurzfassung der Ausgabe von SELECT,
inclusive der Zeit, die die Anfrage benötigte>
mysql> SHOW STATUS;
<Ausgabe von SHOW STATUS>
mysqladmin variables extended-status processlist in
Ihrer Mail mitschicken, um einige Informationen darüber zu geben, wie Ihr
System arbeitet!
mysqldump einen Dump Ihrer
Tabellen machen und eine `README'-Datei erzeugen, die Ihr Problem
beschreibt.
Erzeugen Sie ein komprimiertes Archiv Ihrer Dateien, indem Sie tar
und gzip oder zip benutzen, und benutzen Sie ftp, um
das Archiv nach ftp://Support.mysql.com/pub/mysql/secret/ zu
transferieren. Schicken Sie danach eine kurze Beschreibung des Probleme an
bugs@lists.mysql.com.
ftp benutzen, um die Daten nach
ftp://Support.mysql.com/pub/mysql/secret/ zu transferieren. Falls
die Daten streng geheim sind und Sie sie nicht einmal uns zeigen wollen,
legen Sie bitte ein Beispiel mit anderen Namen an, betrachten Sie dies aber
bitte als allerletzte Möglichkeit.
mysqld-Daemon gestartet haben, und die
Sie für Client-Programme wie mysql benutzen, sowie
diejenigen, die Sie für die Konfiguration des configure-Skripts
nehmen, denn diesen sind oft der Schlüssel für Antworten und deshalb
äußerst relevant!
Es ist immer eine gute Idee, sie in jedem Fall anzugeben! Wenn Sie Module
wie Perl oder PHP benutzen, fügen Sie bitte die Versionszahl von diesen mit
ein.
mysqlaccess, die Ausgabe von mysqladmin reload und alle
Fehlermeldungen, die Sie erhalten, wenn Sie versuchen, sich zu verbinden,
bei! Wenn Sie Ihre Zugriffsberechtigungen testen, sollten Sie zunächst
mysqlaccess ausführen. Führen Sie danach mysqladmin reload
version aus und versuchen Sie dann, sich mit dem Programm zu verbinden,
das Probleme macht. mysqlaccess liegt im `bin'-Verzeichnis
unter Ihrem MySQL-Installationsverzeichnis.
MySQL-Installationsverzeichnis.
parse error erhalten, überprüfen Sie bitte genau Ihre
Syntax! Wenn Sie nichts Falsches darin finden können, ist es sehr
wahrscheinlich, dass Ihre aktuelle Version von MySQL die Anfrage, die Sie
formuliert haben, nicht unterstützt. Wenn Sie die aktuelle Version benutzen
und das Handbuch unter http://www.mysql.com/documentation/manual.php
die Syntax, die Sie benutzen, nicht beschreibt, unterstützt MySQL Ihre
Anfrage nicht. In diesem Fall bleibt Ihnen nur, die Syntax entweder selbst
zu implementieren oder per E-Mail an mysql-licensing@mysql.com
nach einem Angebot für die Implementation anzufragen!
Wenn das Handbuch die Syntax, die Sie benutzen, beschreibt, Sie aber eine
ältere Version von MySQL benutzen, sollten Sie in der
MySQL-Änderungsgeschichte (Change History) nachsehen, wann die Syntax
implementiert wurde. In diesem Fall haben Sie die Möglichkeit, ein Upgrade
auf eine neuere Version von MySQL vorzunehmen.
See section D MySQL-Änderungsverlauf (Change History).
myisamchk oder CHECK
TABLE und REPAIR TABLE benutzen.
See section 5 MySQL-Datenbankadministration.
mysqld NIE eine Tabelle zerstören,
ausser wenn der Server mitten während eines Updates gekillt wurde! Wenn Sie
den Grund für den Absturz von mysqld herausfinden können, ist es
sehr viel einfacher für uns, Ihnen eine Lösung des Problems an die Hand zu
geben!
See section A.1 Wie man feststellt, was Probleme verursacht.
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!
Wenn Sie davon ausgehen, dass Ihre Antwort auf breites Interesse stößt, sollten Sie an die Mailing-Liste posten, statt direkt der Person zu antworten, die die Frage stellte. Versuchen Sie, Ihre Antwort so allgemein zu halten, dass auch andere als der ursprünglich Fragende von Ihrer Antwort profitieren können. Wenn Sie an die Liste posten, stellen Sie bitte sicher, dass Ihre Antwort kein Duplikat einer vorhergehenden Antwort ist.
Versuchen Sie, den wesentlichen Teil der Frage in Ihrer Antwort zusammenzufassen. Fühlen Sie sich nicht verpflichtet, die gesamte ursprüngliche Nachricht zu zitieren.
Bitte schicken Sie Ihre Mailnachrichten nicht im HTML-Format! Viele Benutzer lesen Nachrichten mit nicht HTML-fähigen Anwendungen!
Dieser Abschnitt beschreibt, wie sich MySQL zum ANSI SQL-Standard verhält. MySQL hat viele Erweiterungen zum ANSI SQL-Standard, und hier steht, welche das sind und wie man sie benutzt. Hier finden Sie auch Informationen über Funktionalität, die MySQL fehlt, und wie man mit diesen Unterschieden umgeht.
Entry-Level-SQL92. ODBC-Levels 0-2.
Wir beabsichtigen ANSI SQL99 vollständig zu unterstützen. Dies wollen wir jedoch keinesfalls auf Kosten von Geschwindigkeit oder Codequalität erreichen.
Wenn Sie mysqld mit der --ansi-Option starten, ändert sich
folgendes Verhalten von MySQL:
|| ist Zeichenketten-Verkettung (Konkatenation) anstelle von
OR.
REAL wird zu einem Synonym für FLOAT anstelle eines Synonyms
für DOUBLE.
SERIALIZABLE.
See section 7.7.3 SET TRANSACTION-Syntax.
Das ist dasselbe, als würde man
--sql-mode=REAL_AS_FLOAT,PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE,SERIALIZE,ONLY_FULL_GROUP_BY
benutzen.
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:
MEDIUMINT, SET, ENUM und die
unterschiedlichen BLOB- und TEXT-Typen.
AUTO_INCREMENT, BINARY, NULL,
UNSIGNED und ZEROFILL.
BINARY-Attribut deklarieren oder den BINARY-Cast
benutzen, der dafür sorgt, dass Vergleiche mit der ASCII-Sortierung
durchgeführt werden, die der MySQL-Server-Host benutzt.
db_name.tbl_name-Syntax ansprechen. Einige SQL-Syntax stellen
dieselbe Funktionalität zur Verfügung, nennen dies aber User space.
MySQL unterstützt keine Tablespaces wie in folgendem Beispiel:
create tabelle ralph.meine_tabelle...IN mein_tablespace.
LIKE ist für numerische Spalten erlaubt.
INTO OUTFILE und STRAIGHT_JOIN in einem
SELECT-Statement. See section 7.4.1 SELECT-Syntax.
SQL_SMALL_RESULT in einem SELECT-Statement.
EXPLAIN SELECT, um eine Beschreibung zu erhalten, wie Tabellen
verknüpft werden (Join).
INDEX oder KEY in einem CREATE TABLE-
Statement. See section 7.5.3 CREATE TABLE-Syntax.
TEMPORARY oder IF NOT EXISTS mit CREATE TABLE.
COUNT(DISTINCT list), wobei 'list' mehr als ein
Element ist.
CHANGE spalten_name, DROP spalten_name, oder
DROP INDEX, IGNORE oder RENAME in einem ALTER
TABLE-Statement. See section 7.5.4 ALTER TABLE-Syntax.
RENAME TABLE. See section 7.5.5 RENAME TABLE-Syntax.
ADD-, ALTER-, DROP-, oder
CHANGE-Klauseln in einem ALTER TABLE Statement.
DROP TABLE mit the keywords IF EXISTS.
DROP
TABLE-Statement.
LIMIT-Klausel des DELETE-Statements.
DELAYED-Klausel der INSERT- und REPLACE-
Statements.
LOW_PRIORITY-Klausel der INSERT-, REPLACE-,
DELETE- und UPDATE-Statements.
LOAD DATA INFILE. In vielen Fällen ist diese
Syntax kompatibel mit Oracles LOAD DATA INFILE. See section 7.4.9 LOAD DATA INFILE-Syntax.
ANALYZE TABLE-, CHECK TABLE-, OPTIMIZE TABLE- und
REPAIR TABLE-Statements.
SHOW-Statement.
See section 5.5.5 SHOW-Syntax.
SET OPTION-Statement. See section 6.5.6 SET-Syntax.
GROUP BY-Teil nennen.
Hierdurch ergibt sich eine bessere Performance für einige sehr spezifische,
aber recht gewöhnliche Anfragen.
ASC und DESC bei GROUP BY spezifizieren.
|| und &&, die logisches Oder und
logisches Und bedeuten, wie in der Programmiersprache C. In MySQL sind
|| und OR Synonyme, wie auch && und AND.
Aufgrund dieser freundlichen Syntax unterstützt MySQL nicht den
ANSI-SQL-||-Operator für Zeichenketten-Verkettung (Konkatenation);
benutzen Sie statt dessen CONCAT(). Weil CONCAT() eine
beliebige Anzahl von Argumenten entgegennimmt, ist es leicht, die Benutzung
des ||-Operators zu MySQL zu konvertieren.
CREATE DATABASE oder DROP DATABASE.
See section 7.5.1 CREATE DATABASE-Syntax.
%-Operator ist ein Synonym für MOD(). Das heißt N
% M ist äquivalent zu MOD(N,M). % wird für C-Programmierer
und für Kompatibilität mit PostgreSQL unterstützt.
=-, <>-, <=-, <-, >=-, >-,
<<-, >>-, <=>-, AND-, OR- oder
LIKE-Operatoren können in Spaltenvergleichen links von FROM
in SELECT Statements benutzt werden. Beispiel:
mysql> SELECT spalte1=1 AND spalte2=2 FROM tabelle_name;
LAST_INSERT_ID()-Funktion.
See section 9.4.3.30 mysql_insert_id().
REGEXP- und NOT REGEXP-Operatoren für erweiterte reguläre
Ausdrücke.
CONCAT() oder CHAR() mit einem Argument oder mehr als zwei
Argumenten. (In MySQL können diese Funktionen jede beliebige Anzahl von
Argumenten entgegennehmen.)
BIT_COUNT(), CASE, ELT(),
FROM_DAYS(), FORMAT(), IF(), PASSWORD(),
ENCRYPT(), md5(), ENCODE(), DECODE(),
PERIOD_ADD(), PERIOD_DIFF(), TO_DAYS() oder
WEEKDAY().
TRIM(), um Teile von Zeichenketten zu entfernen.
ANSI SQL unterstützt nur die Entfernung einzelner Zeichen.
GROUP BY-Funktionen STD(), BIT_OR() und
BIT_AND().
REPLACE anstelle von DELETE + INSERT.
See section 7.4.8 REPLACE-Syntax.
FLUSH flush_option-Statement.
:= zu setzen:
SELECT @a:=SUM(total),@b=COUNT(*),@a/@b AS avg FROM test_tabelle; SELECT @t1:=(@t2:=1)+@t3:=4,@t1,@t2,@t3;
Wir versuchen möglichst, dass MySQL dem ANSI-SQL-Standard und dem ODBC-SQL-Standard folgt, aber in einigen Fällen macht MySQL Dinge auf andere Weise:
-- ist nur dann ein Kommentar, wenn darauf Whitespace folgt.
See section 2.7.4.8 `--' als Beginn eines Kommentars.
VARCHAR-Spalten werden Leerzeichen am Ende entfernt, wenn der
Wert gespeichert wird. See section 2.7.5 Bekannte Fehler und Design-Unzulänglichkeiten in MySQL.
CHAR-Spalten automatisch (silent) in
VARCHAR-Spalten. See section 7.5.3.1 Stille Spaltentyp-Änderungen.
REVOKE-Statement
absetzen, um die Zugriffsrechte für eine Tabelle zu widerrufen.
See section 5.3.1 GRANT- und REVOKE-Syntax.
NULL AND FALSE werden zu NULL ausgewertet und nicht zu
FALSE. Der Grund hierfür liegt darin, dass wir meinen, dass es keine
gute Idee ist, eine Menge von Sonderkonditionen für diesen Fall auswerten
zu müssen.
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.
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.
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!
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).
Ab MySQL-Serverversion 3.23.44 unterstützen InnoDB-Tabellen die Prüfung
auf Fremdschlüsselbeschränkungen wie CASCADE, ON DELETE und
ON UPDATE. @xref{InnoDB foreign key constraints}.
Bei anderen Tabellentypen parst der MySQL-Server die FOREIGN KEY-Syntax
in CREATE TABLE-Befehlen lediglich, benutzt oder speichert diese
Informationen jedoch nicht.
Beachten Sie, dass Fremdschlüssel in SQL nicht dazu benutzt werden, um
Tabellen zu verknüpfen, sondern hauptsächlich, um die referentielle
Integrität zu überprüfen (Fremdschlüssel-Restriktionen). Wenn Sie durch ein
SELECT-Statement Ergebnisse aus mehreren Tabellen erhalten wollen,
tun Sie dies, indem Sie Tabellen verknüpfen (Join):
SELECT * FROM table1,table2 WHERE table1.id = table2.id;
See section 7.4.1.1 JOIN-Syntax. See section 4.5.6 Wie Fremdschlüssel (Foreign Keys) verwendet werden.
Wenn Fremdschlüssel (FOREIGN KEYs) als Beschränkung benutzt werden,
müssen sie nicht verwendet werden, wenn eine Applikation Zeilen in der
korrekten Reihenfolge in MyISAM-Tabellen einfügt.
Bei MyISAM-Tabellen können Sie das Problem, dass ON DELETE...
nicht implementiert ist, dadurch umgehen, dass Sie das entsprechende
DELETE-Statement einer Applikation hinzufügen, wenn Sie Datensätze
aus einer Tabelle löschen, die Fremdschlüssel hat. In der Praxis ist das
genauso schnell (in einigen Fällen schneller) und wesentlich portabler, als
wenn Sie Fremdschlüssel benutzen würden.
Beim MySQL-Server 4.0 können Sie das Löschen aus mehreren Tabellen verwenden
(Multi-Table Delete), um mit einem einzigen Befehl Zeilen aus vielen Tabellen
zu löschen. See section 7.4.6 DELETE-Syntax.
Die FOREIGN KEY-Syntax ohne ON DELETE ... wird oft von
ODBC-Applikationen verwendet, um automatische WHERE-Klauseln zu erzeugen.
Die FOREIGN KEY-Implementation wird künftig so erweitert werden, dass
die Informationen in der Tabellendefinitionsdatei gespeichert werden und von
mysqldump und ODBC abgerufen werden können. Für einen späteren Zeitpunkt
ist vorgesehen, auch für MyISAM-Tabellen Fremdschlüsselbeschränkungen
hinzuzufügen.
Denken Sie daran, dass Fremdschlüssel oft falsch eingesetzt werden, was zu schweren Problemen führen kann. Selbst wenn sie korrekt verwendet werden, sind sie keine Zauberlösung für das Problem der referenziellen Integrität, doch können sie solche Dinge erleichtern.
Einige Vorteile der Erzwingung von Fremdschlüsselbeschränkungen sind:
Nachteile:
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:
MySQL unterstützt noch keine Sichten. Die Implementierung von Views ist aber für Version 5.1 geplant.
Sichten sind äußerst nützlich, um Benutzern Zugang zu einem Satz von Beziehungen wie zu einer einzigen Tabelle zu gewähren (Lesezugriff). Viele SQL-Datenbanken lassen es nicht zu, dass irgend welche Zeilen in einer Sicht aktualisiert werden (Update). Statt dessen müssen die einzelnen Tabellen aktualisiert werden.
Weil MySQL meist in Applikationen und in Web-Systemen eingesetzt wird, wo der Applikationsprogrammierer volle Kontrolle über die Datenbankbenutzung hat, sehen die meisten unserer Benutzer Sichten als nicht sehr wichtig an.
In MySQL werden Sichten nicht benötigt, um den Zugriff auf Spalten zu beschränken, weil MySQL ein sehr ausgefeiltes System der Zugriffsberechtigungen hat. See section 5.2 Allgemeine Sicherheitsthemen und das MySQL-Zugriffsberechtigungssystem.
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
Die folgenden Probleme sind bekannt. Ihre Behebung hat eine sehr hohe Priorität:
ANALYZE TABLE kann eine BDB-Tabelle in manchen Fällen unbenutzbar
machen, bis mysqld neu gestartet wird. Wenn so etwas passiert,
stehen Fehlermeldungen wie die folgende in der MySQL-Fehler-Datei (Error
File):
001207 22:07:56 bdb: log_flush: LSN past current end-of-log
BDB-Tabelle nicht ALTER TABLE aus, wenn
Sie mit dieser noch nicht abgeschlossene Mehrfach-Statement-Transaktionen
durchführen. (Die Transaktion wird wahrscheinlich ignoriert.)
ANALYZE TABLE, OPTIMIZE TABLE und REPAIR TABLE können
Probleme bei Tabellen verursachen, für die INSERT DELAYED benutzt
wird.
LOCK TABLE .. und FLUSH TABLES .. benutzen, können
Sie nicht sicher sein, dass bei der fraglichen Tabelle keine halb
abgeschlossenen Transaktionen im Gange sind.
mysql-Client für diese Datenbank benutzen können, wenn Sie die
-A-Option oder rehash benutzen. Das macht sich speziell dann
bemerkbar, wenn Sie einen große Tabellen-Cache benutzen.
LOAD DATA INFILE
und mit Zeilenbegrenzungszeichen (line terminator characters) umgehen, die
mehr als 1 Zeichen enthalten.
Folgende Probleme sind bekannt und werden zu gegebener Zeit behoben:
MATCH nur bei SELECT-Statements.
SET CHARACTER SET benutzen, können Sie keine
landesspezifischen (nationalen) Zeichen für Datenbank-, Tabellen- und
Spaltennamen verwenden (also z. B. kein ä, ö, ü).
DELETE FROM merge_table ohne WHERE löscht nur die Zuordnung
(das Mapping) für die Tabelle, nicht alles in der zugeordneten (gemappten)
Tabelle.
BLOB-Werte können nicht ``zuverlässig'' in GROUP BY-,
ORDER BY oder DISTINCT-Klauseln benutzt werden. In diesen
Fällen werden bei Vergleichen nur die ersten max_sort_length
Bytes (Vorgabewert 1024) von BLOBs benutzt. Die Voreinstellung kann
mit der -O max_sort_length-Option für mysqld geändert werden.
In den meisten Fällen können Sie als Workaround eine Teilzeichenkette
(Substring) verwenden: SELECT DISTINCT LEFT(blob,2048) FROM
tabelle.
BIGINT oder DOUBLE durchgeführt
(beide sind normalerweise 64 Bits lang). Es hängt von der verwendeten
Funktion ab, welche Genauigkeit man erhält. Als allgemeine Regel gilt, dass
Bit-Funktionen mit BIGINT-Genauigkeit, IF und ELT()
mit BIGINT- oder DOUBLE-Genauigkeit und der Rest mit
DOUBLE-Genauigkeit durchgeführt werden. Man sollte vermeiden,
vorzeichenlose Werte, die größer als 63 Bits sind (9223372036854775807),
zu verwenden, ausser für Bit-Felder!
MySQL 4.0 bietet eine bessere BIGINT-Handhabung als MySQL 3.23.
BLOB- und
TEXT-Spalten werden Leerzeichen am Ende automatisch entfernt, wenn
sie abgerufen werden. Bei CHAR-Typen ist das okay und kann gemäß
ANSI-SQL92 als ein Feature betrachtet werden. Der Bug besteht darin, dass
in MySQL auch VARCHAR-Spalten auf dieselbe Art behandelt werden.
ENUM- und SET-Spalten
verwendet werden.
safe_mysqld leitet alle Nachrichten von mysqld in die
mysqld-Logdatei um. Ein Problem ergibt sich, wenn Sie
mysqladmin refresh benutzen, um die Logdatei zu schließen und
wieder zu öffnen. In diesem Fall werden stdout und stderr
immer noch in die alte Logdatei geleitet.
Wenn Sie --log umfangreich benutzen, sollten Sie safe_mysqld
editieren, um in `'hostname'.err' anstelle von `'hostname'.log'
zu loggen, damit Sie den Speicherplatz für das alte Log leicht neu belegen
können, indem Sie das alte Log löschen und mysqladmin refresh
ausführen.
UPDATE-Statement, werden Spalten von links nach rechts
aktualisiert (Update). Wenn Sie sich auf eine aktualisierte Spalte
beziehen, erhalten Sie den aktualisierten Werte anstelle des ursprünglichen
Werts. Beispiel:
mysql> UPDATE tabelle SET KEY=KEY+1,KEY=KEY+1;Dieses Statement aktualisiert
KEY mit 2 anstelle von
1.
select * from temporaere_tabelle, temporaere_tabelle as t2;
RENAME funktioniert nicht bei TEMPORARY-Tabellen.
DISTINCT
unterschiedlich, je nachdem, ob Sie 'versteckte' Spalten in einem Join
benutzen oder nicht. In einem Join werden versteckte Spalten als Teil des
Ergebnisses gezählt (selbst wenn sie nicht angezeigt werden), während
versteckte Spalten in normalen Anfragen nicht an einem DISTINCT-Vergleich
teilnehmen. Zukünftig werden wir dieses Verhalten wahrscheinlich ändern, so
dass versteckte Spalten nie verglichen werden, wenn DISTINCT ausgeführt
wird.
Hierfür ein Beispiel:
SELECT DISTINCT mp3id FROM band_downloads WHERE userid = 9 ORDER BY id DESC;und
SELECT DISTINCT band_downloads.mp3id, FROM band_downloads,band_mp3 WHERE band_downloads.userid = 9 AND band_mp3.id = band_downloads.mp3id ORDER BY band_downloads.id DESC;Im zweiten Fall bekommen Sie in MySQL 3.23.x möglicherweise zwei identische Zeilen in der Ergebnismenge (weil die versteckten 'id'-Spalten unterschiedlich sein können). Beachten Sie, dass dies nur für Anfragen zutrifft, bei denen die ORDER BY-Spalten nicht im Ergebnis enthalten sind. ANSI-SQL erlaubt dies nicht
rollback in
den vorherigen Zustand bringen können), verhalten sich einige Dinge in
MySQL etwas anderes als in anderen SQL-Servern. Das kann manchmal etwas
ungünstig sein, weil Spaltenwerte in der Applikation überprüft werden
müssen. Auf der anderen Seite erhalten Sie dadurch eine nette
Geschwindigkeitssteigerung, weil es MySQL gestattet, einige Optimierungen
vorzunehmen, die ansonsten sehr schwer durchzuführen sein würden.
Wenn Sie eine Spalte auf einen nicht zulässigen Wert setzen, speichert
MySQL, statt ein Rollback durchzuführen, den besten möglichen Wert
in der Spalte:
NULL in einer Spalte zu speichern, die keine
NULL-Werte zuläßt, speichert MySQL 0 oder '' (leere
Zeichenkette). (Man kann dieses Verhalten jedoch mit der
-DDONT_USE_DEFAULT_FIELDS-Kompilierungs-Option ändern.)
DATE- und
DATETIME-Spalten gespeichert werden (wie 2000-02-31 oder
2000-02-00). Wenn das Datum völlig falsch ist, speichert MySQL den
speziellen Datumswert 0000-00-00 in der Spalte.
enum auf einen nicht unterstützten Wert setzen, wird es auf
den Fehlerwert 'leere Zeichenkette' oder (bei numerischen Werten) auf 0
gesetzt.
PROCEDURE auf eine Anfrage ausführen, die eine leere
Ergebnismenge liefert, kann es in einigen Fällen vorkommen, dass
PROCEDURE die Spalten nicht umwandelt.
MERGE anlegen, wird nicht überprüft,
ob die zugrunde liegenden Tabellen von einem kompatiblen Typ sind.
NaN-, -Inf- und
Inf-Werten in Doubles umgehen. Wenn Sie diese benutzen, gibt es
Probleme, wenn Daten importiert oder exportiert werden. Als Zwischenlösung
sollten Sie NaN in NULL umwandeln (falls möglich) und
-Inf und Inf in den kleinsten bzw. größten möglichen Wert.
LIMIT-Klausel werden als große positive
Zahlen behandelt.
ALTER TABLE benutzen, um einen UNIQUE-Index zu einer
Tabelle hinzuzufügen, die in einer MERGE-Tabelle benutzt wird, und
dann ALTER TABLE benutzen, um der MERGE-Tabelle einen
normalen Index hinzuzufügen, weicht die Reihenfolge der Schlüssel für die
Tabellen ab. Das liegt daran, dass ALTER TABLE
UNIQUE-Schlüssel vor normalen Schlüsseln einfügt, um doppelte
Schlüssel so früh wie möglich erkennen zu können.
Folgende bekannte Bugs gibt es in früheren Versionen von MySQL:
DROP TABLE auf
eine Tabelle ausführt, die zu vielen Tabellen gehört, die mit LOCK
TABLES gesperrt sind.
LOCK tabelle mit WRITE
FLUSH TABLES
UPDATE fehlschlagen, dass einen
Schlüssel mit einer WHERE-Klausel auf denselben Schlüssel
aktualisiert, weil der Schlüssel benutzt wurde, um nach Datensätzen zu
suchen, und dieselbe Zeile mehrfach gefunden wurde:
UPDATE tabelle SET KEY=KEY+1 WHERE KEY > 100;Ein Workaround besteht in der Benutzung von:
mysql> UPDATE tabelle SET KEY=KEY+1 WHERE KEY+0 > 100;Das funktioniert, weil MySQL auf Ausdrücke (Expressions) in der
WHERE-Klausel keine Indizes benutzt.
Was Plattform-spezifische Bugs angeht, sehen Sie bitte im Abschnitt über Kompilieren und Portieren nach.
Dieser Anhang listet die Features auf, für die wir eine Implementierung in MySQL geplant haben.
Alles auf dieser Liste gibt nur ungefähr die Reihenfolge wieder, in der es gemacht werden wird. Wenn Sie die Prioritäten beeinflussen wollen, registrieren Sie bitte eine Lizenz oder unterstützen Sie uns und teilen uns mit, was Sie schneller gemacht haben wollen. See 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.
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).
.frm-Dateien). Das
versetzt uns in die Lage, nicht irgendwann keine Bits mehr zu haben, wenn
wir weitere Tabellenoptionen hinzufügen. Es wird nach wie vor möglich sein,
in 4.0 das alte .frm-Dateiformat zu benutzen. Alle neu erzeugten
Tabellen werden jedoch das neue Format benutzen.
Das neue Dateiformat versetzt uns in die Lage, neue Spaltentypen, mehr
Optionen für Schlüssel und FOREIGN KEY-Support hinzuzufügen.
RAND() und Benutzer-Variablen
@var funktionieren.
DELETE auf MyISAM-Tabellen den
Datensatz-Cache benutzt. Um das zu tun, müssen wir den Thread-Cache für
Datensätze aktualisieren, wenn wir die .MYD-Datei aktualisieren.
SHOW COLUMNS FROM tabelle (der vom mysql-Client benutzt für
die Erweiterung von Spaltennamen benutzt wird) sollte nicht die Tabelle
öffnen, sondern nur die Definitionsdatei. Das wird weniger Speicher
beanspruchen und sehr viel schneller sein.
SET CHARACTER SET sollten wir die gesamte
Anfrage übersetzen und nicht nur Zeichenketten. Das würde Benutzern
ermöglichen, landesspezifische Zeichen auch in Datenbank-, Tabellen- und
Spaltenamen zu benutzen.
gethostbyaddr_r(),
damit wir ip_to_hostname() davon abhalten können, andere Threads zu
blockieren, während es DNS-Lookups durchführt.
record_in_range()-Methode zu MERGE-Tabellen,
um den richtigen Index auswählen zu können, wenn es viele gibt, aus denen
ausgewählt werden kann. Wir sollten auch die info-Schnittstelle erweitern,
um die Schlüsselverteilung für jeden Index zu erhalten, wenn analyze
über alle Unter-Tabellen läuft.
SET SQL_DEFAULT_TABLE_TYPE=[MyISAM | INNODB | BDB | HEAP].
select id from t where grp in (select grp from g where u > 100)
update items,month set
items.price=month.price where items.id=month.id;;
select a.col1, b.col2 from (select max(col1) as col1 from root_table ) a, other_table b where a.col1=b.col1Das könnte erreicht werden, indem für die Dauer der Anfrage automatisch temporäre Tabellen für die abgeleiteten Tabellen erzeugt werden.
PREPARE von Statements und Senden von Parametern an
mysqld.
INSERT ... SELECT ändern, um optional konkurrierende Inserts zu
benutzen.
RENAME DATABASE implementieren. Damit das sicher für alle
Tabellen-Handler funktioniert, sollte es wie folgt laufen:
RENAME-Befehl machen.
SELECT MIN(column)... GROUP
BY ausgeführt wird.
mysqld.
long_query_time mit einer Auflösung in
Mikrosekunden festzulegen.
mysql-Kommandozeilen-Werkzeug, mit Optionen wie Datenbank in Benutzung,
Zeit und Datum ...
MERGE-Tabellen.
myisampack-Code in den Server einlinken.
INSERT/DELETE/UPDATE, um den vorherigen Zustand elegant
wiederherstellen zu können, wenn der Index voll wird.
ALTER TABLE auf eine Tabelle durchgeführt wird, die per
Symlink auf einer anderen Festplatte ist, temporäre Tabellen auf dieser
Festplatte erzeugen.
DATE/DATETIME-Typs, der
Zeitzonen-Informationen sauber handhabt, damit der Umgang mit Datumswerten
in verschiedenen Zeitzonen leichter wird.
MyISAM)
ohne Threads kompilieren kann.
INSERT SQL_CONCURRENT und mysqld --concurrent-insert sollen
ein konkurrierendes Insert am Ende der Datei machen, falls die Datei
lese-gesperrt ist.
FOREIGN-Key-Festlegungen in der `.frm'-Datei speichern.
DELETE)
lockd mit modernen Linux-Kernels funktioniert; wenn
nicht, müssen wir lockd überarbeiten! Um das zu testen, startet man
mysqld mit --enable-locking und läßt die verschiedenen fork*
test suits laufen. Sie sollten keine Fehler produzieren, wenn lockd
funktioniert.
LIMIT zulassen, wie LIMIT @a,@b.
UPDATE-Statements zulassen, zum
Beispiel: UPDATE TABLE foo SET @a=a+b,a=@a, b=@a+c
GROUP BY benutzen kann wie in folgendem Beispiel:
SELECT id, @a:=count(*), sum(sum_col)/@a FROM tabelle GROUP BY id.
DEFAULT-Werte zu Spalten hinzufügen. Fehler
ausgeben, wenn ein INSERT benutzt wird, dass keine Spalte enthält,
die keinen DEFAULT-Wert hat.
SELECT CACHED ...
zu cachen.
mysql_query()-Befehle in
einer Zeile stehen können, ohne dass Ergebnisse gelesen werden oder man
eine nette Fehlermeldung erhält, wenn man das tut.
BIT-Typs, so dass er 1 Bit aufnimmt (momentan nimmt
BIT 1 Zeichen auf).
ctime() auf einigen FreeBSD-Systemen
nicht funktioniert.
IMAGE-Option zu LOAD DATA INFILE, damit
TIMESTAMP- und AUTO_INCREMENT-Felder nicht aktualisiert
werden.
LOAD DATE INFILE.. UPDATE-Syntax hinzufügen.
LOAD DATA INFILE ...
REPLACE INTO.
LOAD DATA INFILE soll auch folgende Syntax verstehen:
LOAD DATA INFILE 'datei.txt' INTO TABLE tabelle TEXT_FIELDS (text_feld1, text_feld2, text_feld3) SET tabelle_feld1=concatenate(text_feld1, text_feld2), tabelle_feld3=23 IGNORE text_feld3 Das kann benutzt werden, um zusätzliche Spalten in der Textdatei zu überspringen oder um Spalten basierend auf Ausdrücken in den gelesenen Daten zu aktualisieren ...
LOAD DATA INFILE 'datei' INTO TABLE 'tabelle' ERRORS TO err_tabelle
Das würde bewirken, dass alle Fehler und Warnungen in der err_tabelle
mitgeschrieben werden. Diese Tabelle hätte etwa folgende Struktur:
zeile_nummer - Zeilennummer in der Datendatei fehler_nachricht - die Fehler-/Warnungs-Nachricht und vielleicht daten_zeile - die Zeilennummer der Datendatei
VARCHAR-Unterstützung (gibt es schon in
MyISAM).
mysql an Netscape.
LOCK DATABASES. (mit vielerlei Optionen)
DECIMAL- und NUMERIC-Typen können keine exponentiellen Zahlen
lesen; Field_decimal::store(const char *from,uint len) muss neu
kodiert werden, um das zu beheben.
mysql.cc überarbeiten, damit weniger malloc()-Aufrufe
durchgeführt werden, wenn Feldnamen gehasht werden.
t1 JOIN t2 ON ... und t1 JOIN t2 USING ...
hinzufügen. Momentan kann man diese Syntax nur mit LEFT JOIN
benutzen.
unsigned long long-Typen hinzufügen.
show status. Zähler für:
INSERT-/DELETE-/UPDATE-Statements. Gelesene und
aktualisierte Datensätze. Select auf 1 Tabelle und Selects mit Joins.
Durchschnittliche Anzahl von Tabellen in Selects. Anzahl von ORDER
BY- und GROUP BY-Anfragen.
mysql mitten in einer Anfrage abbricht, sollte man eine
neue Verbindung herstellen und die alte, laufende Anfrage killen.
Alternativ könnte man den Versuch unternehmen, so etwas im Server zu
entdecken.
SHOW INFO FROM tabelle für Basisinformationen über Tabellen sollte
implementiert werden.
NATURAL JOIN und UNION JOIN.
select a from crash_me left join crash_me2 using (a)
zulassen; in diesem Fall wird angenommen, dass a aus der crash_me-Tabelle
kommt.
ON und USING mit dem
JOIN-Verknüpfungstyp funktioniert.
CONNECT BY PRIOR ..., um hierarchische Strukturen zu
durchsuchen.
mysqladmin copy datenbank neue_datenbank. -- Erfordert, dass
mysqld der COPY-Befehl hinzugefügt wird.
SHOW HOSTS zur Informationsausgaben über den Hostnamen-Cache.
DATETIME ändern, um Bruchteile von Sekunden zu speichern.
NULL
ändern.
SELECT COUNT(*)*(id+0) FROM tabelle GROUP BY id
ALTER TABLE sollte nicht mehr Clients abbrechen, die INSERT
DELAYED ausführen.
UPDATE-Klausel
verwiesen wird, die alten Werte enthalten, bevor das Update begonnen wird.
myisamchk, REPAIR und OPTIMIZE TABLE sollten in der
Lage sein, mit Fällen umzugehen, wo die Daten und / oder Indexdateien
symbolische Links sind.
pread()/pwrite() auf Windows einarbeiten, um
konkurrierende Inserts zu ermöglichen.
SUM(DISTINCT)
ANY()-,EVERY()- und SOME()-Gruppierungsfunktionen
hinzufügen. In ANSI-SQL funktionieren diese auf boolsche Spalten, aber wir
können sie so erweitern, dass sie mit beliebigen Spalten / Ausdrücken
funktionieren, indem wir folgendes anwenden: wert == 0 -> FALSE und
wert <> 0 -> TRUE.
MAX(column) vom selben Typ ist wie der
Spaltentyp.
create tabelle t1 (a DATE); insert into t1 values (now()); create tabelle t2 select max(a) von t1; show columns from t2;
UPDATE ausführt, wenn sie existiert, und eine neue Zeile einfügt
(INSERT), wenn sie nicht existiert (so wie REPLACE bei
INSERT / DELETE funktioniert).
get_changed_tables(timeout,table1,table2,...)
SHOW-Befehle
hinzufügen.
SET TIMESTAMP=#;
UNION, MINUS, INTERSECT und FULL OUTER JOIN.
(Momentan wird nur LEFT OUTER JOIN unterstützt.)
UNIQUE bei Feldern zulassen, die NULL sein können.
SQL_OPTION MAX_SELECT_TIME=# um einer Anfrage eine Zeitbeschränkung
zu setzen.
LIMIT-Parameter, um Daten vom Ende abrufen zu können.
safe_mysqld: Nach FSSTND (woran
sich Debian versucht zu halten) sollten PID-Dateien als
`/var/run/<progname>.pid' angelegt werden und Log-Datei in
`/var/log'. Es wäre nett, wenn man "DATADIR" in die erste Deklaration
von "pidfile" und "log" packen könnte, damit die Unterbringung dieser
Dateien mit einem einzigen Statement geändert werden könnte.
zlib() für gzip-te Dateien in LOAD DATA
INFILE zulassen.
BLOB-Spalten in Ordnung bringen
(teilweise bereits gelöst).
AUTO_INCREMENT-Wert zuweisen, wenn eine Spalte auf 0
gesetzt wird. Statt dessen NULL setzen.
JOIN) mit Klammern.
GET_LOCK zu
erhalten. Wenn man das tut, muss man die möglichen Deadlocks handhaben, die
diese Änderung einführen wird.
Zeitangaben stehen für den Umfang der Arbeit, nicht für echte Zeit.
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.
mSQLmSQL in folgenden Punkten schneller sein:
INSERT-Operationen auf sehr einfache Tabellen mit wenigen Spalten
und Schlüsseln.
CREATE TABLE und DROP TABLE.
SELECT auf alles, was kein Index ist. (Ein Tabellen-Scan ist sehr
einfach.)
mSQL (und den meisten
anderen SQL-Implementationen) bei Folgendem:
SELECT-Operationen.
VARCHAR-Spalten haben.
SELECT mit vielen Ausdrücken.
SELECT auf große Tabellen.
mSQL müssen nach dem Verbindungsaufbau alle anderen warten, bis die
erste Verbindung beendet wurde, egal, ob diese Verbindung eine Anfrage
ausführt, die kurz oder lang ist. Wenn die erste Verbindung abgebaut wird,
kann die zweite bedient werden, während alle anderen noch warten, usw.
mSQL kann krankhaft langsam werden, wenn Sie die Reihenfolge von
Tabellen in einem SELECT-Statement ändern. In einem Benchmark-Test
wurde beobachtet, dass es mehr als 15000-mal langsamer werden kann als
MySQL. Das liegt daran, dass mSQL keinen Verknüpfungs-Optimierer
(Join Optimizer) besitzt, der die Tabellen in optimale Reihenfolge bringt.
Wenn Sie allerdings exakt die richtige Reihenfolge in mSQL2 benutzen
und wenn die WHERE-Klausel einfach ist und Spalten-Indexe benutzt,
wird die Verknüpfung relativ schnell sein!
See section 6.1.4 Die MySQL-Benchmark-Suite.
ORDER BY und GROUP BY.
DISTINCT.
TEXT- oder BLOB-Spalten.
GROUP BY und HAVING.
mSQL unterstützt GROUP BY überhaupt nicht.
MySQL unterstützt GROUP BY vollständig, sowohl mit HAVING als
auch mit den folgenden Funktionen: COUNT(), AVG(), MIN(),
MAX(), SUM() und STD(). COUNT(*) ist darauf
optimiert, sehr schnell Ergebnisse zu liefern, wenn SELECT aus einer
Tabelle abfragt, wenn keine andere Spalte abgerufen wird und wenn es keine
WHERE-Klausel gibt. MIN() und MAX() können
Zeichenketten-Argumente entgegennehmen.
INSERT und UPDATE mit Berechnungen.
MySQL kann Berechnungen in INSERT- oder UPDATE-Statements
ausführen. Beispiel:
mysql> UPDATE SET x=x*10+y WHERE x<20;
SELECT mit Funktionen.
MySQL hat viele Funktionen (zu viele, um sie hier aufzulisten; siehe
section 7.3 Funktionen für die Benutzung in SELECT- und WHERE-Klauseln).
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.
mSQL, daher
können wir nichts darüber sagen.
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.)
mSQL, mit
einigen zusätzlichen Features.
mSQL einen JDBC-Treiber hat, aber wir haben zu
wenig Erfahrung damit, um ihn in einen Vergleich einzubeziehen.
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.
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.
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:
msql2mysql über den Quelltext laufen.
Das erfordert das replace-Programm, das mit MySQL ausgeliefert wird.
Die Unterschiede zwischen der mSQL-C-API und der MySQL-C-API sind:
MYSQL-Struktur als Verbindungstyp, (mSQL
benutzt einen int).
mysql_connect() nimmt einen Zeiger (Pointer) auf eine
MYSQL-Struktur als Parameter auf. Es ist einfach, einen global zu
definieren oder malloc() zu benutzen, um einen zu erhalten.
mysql_connect() nimmt zusätzlich zwei Parameter auf, um Benutzer und
Passwort zu spezifizieren. Sie können diese als Vorgabewert der Benutzung
auf NULL, NULL setzen.
mysql_error() nimmt die MYSQL-Struktur als Parameter auf.
Fügen Sie einfach den Parameter zu Ihrem alten msql_error()-Code
hinzu, wenn Sie alten Code portieren.
mSQL gibt nur eine Fehlernachricht zurück.
mSQL- und MySQL-Client/Server-Kommunikationsprotokolle unterscheidenEs 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:
mSQL 2.0 SQL-Syntax von MySQL unterscheidetSpaltentypen
CREATE TABLE-Syntax):
ENUM-Typ für einen Satz von Zeichenketten.
SET-Typ für viele Sätze von Zeichenketten.
BIGINT-Typ für 64-Bit-Ganzzahlen (Integer).
UNSIGNED-Option für Ganzzahl-Spalten (Integer).
ZEROFILL-Option für Ganzzahl-Spalten (Integer).
AUTO_INCREMENT-Option für Ganzzahl-Spalten (Integer), die ein
PRIMARY KEY sind.
See section 9.4.3.30 mysql_insert_id().
DEFAULT-Wert für alle Spalten.
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
CREATE
TABLE-Statement festgelegt werden.
mSQL
CREATE INDEX-Statements.
Einfügen eines eindeutigen Identifikators (Unique Identifier) in eine Tabelle
MySQL
AUTO_INCREMENT als Spaltentyp-Spezifizierer.
See section 9.4.3.30 mysql_insert_id().
mSQL
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
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
_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
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
_timestamp-Spalte .
NULL-Wert-Vergleiche
MySQL
NULL immer zu
NULL ausgewertet.
mSQL
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
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
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
CLIKE.
Handhabung von Leerzeichen am Ende
MySQL
CHAR- und
VARCHAR-Spalten. Benutzen Sie eine TEXT-Spalte, wenn dieses
Verhalten unerwünscht ist.
mSQL
WHERE-Klauseln
MySQL
AND wird vor OR
ausgewertet). Um mSQL-Verhalten in MySQL zu erreichen, benutzen
Sie Klammern (wie im unten stehenden Beispiel gezeigt).
mSQL
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
mSQL
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.
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.
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:
MySQL ist generell viel schneller als PostgreSQL.
See section 2.9.2.3 Benchmark-Vergleiche von MySQL und PostgreSQL.
VACUUM()
laufen lassen muss, um durch UPDATE- und DELETE-Kommandos
beanspruchten Platz zurück zu gewinnen, sowie um statistische Analysen
durchzuführen, die entscheidend sind, um mit PostgreSQL gute Performance zu
erzielen. VACUUM() wird auch benötigt nach dem Hinzufügen vieler
Zeilen in eine Tabelle. Auf einem ausgelasteten System mit vielen
Änderungen muss VACUUM() sehr häufig laufen gelassen werden, im
schlimmsten Fall mehrmals täglich. Während VACUUM() läuft, was
Stunden dauern kann, wenn die Datenbank Groß ist, ist die Datenbank vom
Produktionsstandpunkt her gesehen praktisch tot. Das PostgreSQL-Team hat
die Behebung dessen auf seiner TODO-Liste, aber wir vermuten, dass es nicht
einfach sein wird, das dauerhaft zu beheben.
PostgreSQL.
ALTER TABLE.
HEAP-Tabellen oder Festplatten-basierend
MyISAM sein. See section 8 MySQL-Tabellentypen.
BerkeleyDB und InnoDB. Weil jede
Transaktions-Engine unter unterschiedlichen Bedingungen unterschiedlich
leistungsfähig ist, gibt das dem Applikationsschreiber mehr Optionen, die
optimale Lösung für seinen Bedarf zu finden. See section 8 MySQL-Tabellentypen.
MERGE-Tabellen geben Ihnen eine einzigartige Möglichkeit, eine
augenblickliche Sicht (View) über eine Reihe identischer Tabellen zu machen
und diese wie eine zu benutzen. Das ist perfekt für Systeme, auf denen Sie
Log-Dateien haben, die Sie zum Beispiel nach Monat sortieren. See section 8.2 MERGE-Tabellen.
INSERT-, SELECT- und
UPDATE/DELETE-Rechtegewährung (Grants) pro Benutzer auf eine
Datenbank oder Tabelle. MySQL dagegen erlaubt es Ihnen, einen kompletten
Satz unterschiedlicher Zugriffsrechte auf Datenbank-, Tabellen- und
Spaltenebene festzulegen. MySQL gestattet es auch, Zugriffsrechte als
Host- und Benutzer-Kombinationen festzulegen. See section 5.3.1 GRANT- und REVOKE-Syntax.
Nachteile von MySQL im Vergleich zu PostgreSQL:
MyISAM-Tabellen benutzt werden, sind in vielen Fällen schneller als
Seiten-Sperren (Page Locks), Zeilen-Sperren (Row Locks) oder Versionierung
(Versioning). Der Nachteil liegt jedoch darin, dass, wenn man nicht
berücksichtigt, wie Tabellensperren funktioniert, eine einzige lang
laufende Anfrage eine Tabelle lange Zeit für Updates blockieren kann. Das
kann gewöhnlich durch entsprechenden Entwurf der Applikation vermieden
werden. Falls nicht, kann man immer noch die Tabelle, die das Problem
verursacht, zu einem der transaktionalen Tabellentypen umändern.
See section 6.3.2 Themen, die Tabellensperren betreffen.
UPDATE behoben sein und in MySQL 4.1 mit den Subselects.
In MySQL 4.0 kann man Multi-Table-Deletes nutzen, um zeitgleich in mehreren
Tabellen zu löschen. See section 7.4.6 DELETE-Syntax.
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:
VACUUM() macht es problematisch, PostgreSQL in 24/7-Umgebungen
einzusetzen.
INSERT, DELETE und UPDATE Anweisungen.
Eine vollständige Aufstellung der Nachteile finden Sie in der ersten Tabelle dieses Abschnitts.
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.
VACUUM() vor dem Test) und dass sie das Starten vor dem
Test getuned haben, etwas, das sie für keine der anderen getesteten
Datenbanken gemacht haben. Dazu heißt es: ``Dieser Prozess optimiert
Indexe und gibt etwas Festplattenspeicher frei. Die optimierten Indexe
steigern die Performance um etliches.'' Unsere Benchmarks zeigen deutlich,
dass der Unterschied bei einer großen Menge von Selects auf eine Datenbank
mit und ohne VACUUM() leicht Faktor zehn betragen kann.
SELECTs und JOINs
(speziell nach einem VACUUM()), performt aber nicht so gut bei
INSERTs oder UPDATEs. Die Benchmarks scheinen anzuzeigen,
dass nur SELECTs durchgeführt wurden (oder sehr wenige Updates). Das
würde die guten Ergebnisse für PostgreSQL in diesem Test erklären. Etwas
weiter unten wird erläutert, wie es zu den schlechten Ergebnissen für MySQL
kam.
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.
Werbung: Auserlesene Weine finden Sie unter Weine Wein! Ökologisch korrekt angebaute Bioweine gibt es bei Bioweine.biz