MySQL 5.1 Referenzhandbuch

Bitte senden Sie keine Mails mit aktiviertem HTML-Modus aus Ihrem Browser. Viele Benutzer lesen ihre Mails nicht mit einem Browser.

Wenn Sie eine Frage beantworten, die an die Mailingliste gesendet wurde, und der Ansicht sind, dass die Antwort von allgemeinem Interesse ist, dann sollten Sie sie an die Liste schicken, statt dem Fragesteller direkt zu schreiben. Formulieren Sie Ihre Antwort allgemein genug, sodass auch andere Benutzer als der Fragesteller davon profitieren können. Bevor Sie einen Beitrag an die Liste schicken, vergewissern Sie sich, dass es sich nicht um eine Wiederholung einer bereits vorhandenen Antwort handelt.

Versuchen Sie, die wesentlichen Aspekte der Frage in der Antwort zusammenzufassen. Sie sind nicht verpflichtet, die gesamte Frage in ihrer ursprünglichen Form zu zitieren.

Wenn Antworten direkt an Sie und nicht an die Mailingliste geschrieben werden, gilt es als lobenswert, die Antworten in zusammengefasster Form an die Liste zu schicken, sodass auch andere Benutzer von den Antworten profitieren können, mit deren Hilfe Sie das Problem beheben konnten.

MySQL 4.1 und höher unterstützen Unterabfragen und abgeleitete Tabellen. Eine „Unterabfrage“ ist eine SELECT-Anweisung, die mit einer anderen Anweisung verschachtelt ist. Eine „abgeleitete Tabelle“ (eine unbenannte Sicht) ist eine Unterabfrage in der FROM-Klausel einer anderen Anweisung. Siehe auch Abschnitt 13.2.8, „Syntax von Unterabfragen“.

Bei MySQL-Versionen vor 4.1 können die meisten Unterabfragen mithilfe von Joins oder anderer Methoden umformuliert werden. Beispiele zu dieser Vorgehensweise finden Sie unter Abschnitt 13.2.8.11, „Umschreiben von Unterabfragen in Joins für frühere MySQL-Versionen“.

MySQL Server unterstützt die Sybase SQL-Erweiterung SELECT ... INTO TABLE nicht. Stattdessen verwendet MySQL Server die Standard-SQL-Syntax INSERT INTO ... SELECT, mit der im Wesentlichen das Gleiche erreicht werden kann. Siehe auch Abschnitt 13.2.4.1, „INSERT ... SELECT“. Ein Beispiel:

INSERT INTO tbl_temp2 (fld_id)
    SELECT tbl_temp1.fld_order_id
    FROM tbl_temp1 WHERE tbl_temp1.fld_order_id > 100;

Alternativ können Sie auch SELECT ... INTO OUTFILE oder CREATE TABLE ... SELECT verwenden.

Ab MySQL 5.0 können Sie SELECT ... INTO mit benutzerdefinierten Variablen verwenden. Die gleiche Syntax kann ebenfalls in gespeicherten Routinen mithilfe von Cursorn und lokalen Variablen eingesetzt werden. Siehe auch Abschnitt 19.2.7.3, „SELECT ... INTO-Anweisung“.

Die Versionen 3.23-max und alle Versionen ab 4.0 von MySQL Server unterstützen Transaktionen mit transaktionalen InnoDB- und BDB-Speicher-Engines. InnoDB bietet vollständige ACID-Konformität. Siehe auch Kapitel 14, Speicher-Engines und Tabellentypen. Informationen zu InnoDB-spezifischen Unterschieden zu Standard-SQL bezüglich der Behandlung von Transaktionsfehlern finden Sie in Abschnitt 14.2.15, „InnoDB-Fehlerbehandlung“.

Die anderen nichttransaktionalen Speicher-Engines in MySQL Server (wie etwa MyISAM) folgen einem anderen Muster der Datenintegrität, welches „atomare Operationen“ genannt wird. Aus transaktionaler Sicht arbeiten MyISAM-Tabellen quasi immer im Modus AUTOCOMMIT=1. Atomare Operationen bieten häufig vergleichbare Integrität bei besserer Leistung.

Da MySQL Server beide Muster unterstützt, können Sie selbst entscheiden, ob Ihre Anwendungen besser mit der Geschwindigkeit atomarer Operationen oder der Verwendung der Transaktionsfunktionalität bedient sind. Diese Auswahl lässt sich pro Tabelle treffen.

Wie bereits angemerkt, fällt die Entscheidung zwischen transaktionalen und nichttransaktionalen Speicher-Engines in erster Linie aufgrund von Leistungsanforderungen. Transaktionale Tabellen haben einen wesentlich höheren Bedarf an Speicher- und Festplattenkapazität und benötigen zudem mehr Prozessorleistung. Andererseits bieten transaktionale Speicher-Engines wie InnoDB auch viele wesentliche Vorteile. Der modulare Aufbau von MySQL Server erlaubt die gleichzeitige Nutzung verschiedener Speicher-Engines zur Erfüllung unterschiedlicher Bedürfnisse und für optimale Leistung in allen Situationen.

Wie aber nutzen Sie nun die Funktionen von MySQL Server zur Aufrechterhaltung einer strikten Integrität auch bei nichttransaktionalen MyISAM-Tabellen, und wie stehen diese Funktionen im Vergleich mit transaktionalen Speicher-Engines da?

Das transaktionale Muster hat Vor- und Nachteile. Viele Benutzer und Anwendungsentwickler wissen die Einfachheit zu schätzen, sich um Probleme „herumzuprogrammieren“, bei denen ein Abbruch erforderlich ist oder erforderlich zu sein scheint. Doch sogar dann, wenn Sie mit dem atomaren Operationsmuster noch nicht oder mit Transaktionen recht gut vertraut sind, sollten Sie den Geschwindigkeitsvorteil berücksichtigen, den nicht transaktionale Tabellen bieten; immerhin liegt die Verarbeitungsgeschwindigkeit drei- bis fünfmal höher als bei optimal programmierten transaktionalen Tabellen.

In Situationen, in denen die Integrität eine entscheidende Rolle spielt, bietet MySQL Server die Zuverlässigkeit und Integrität transaktionaler Tabellen auch für nichttransaktionale Tabellen. Wenn Sie Tabellen mit LOCK TABLES sperren, werden alle Updates so lange angehalten, bis die Integritätsprüfungen durchgeführt wurden. Wenn Sie eine READ LOCAL-Sperre (im Gegensatz zur Schreibsperre) für eine Tabelle setzen, die gleichzeitiges Einfügen am Tabellenende gestattet, ist das Lesen ebenso möglich wie das Einfügen durch andere Clients. Der Client, für den die Lesesperre gesetzt ist, sieht die neu hinzugefügten Datensätze erst, wenn die Sperre aufgehoben wird. Mit INSERT DELAYED können Sie Einfügungen schreiben, die in eine lokale Warteschlange aufgenommen werden, bis die Sperren aufgehoben wurden. In diesem Fall muss der Client nicht warten, bis der Einfügevorgang abgeschlossen ist. Siehe auch Abschnitt 7.3.3, „Gleichzeitige Einfügevorgänge“, und Abschnitt 13.2.4.2, „INSERT DELAYED“.

„Atomar“, wie wir es hier verstehen, hat nichts mit Zauberei zu tun. Damit ist lediglich gemeint, dass gewährleistet ist, dass, solange ein bestimmtes Update durchgeführt wird, dieses von keinem anderen Benutzer unterbrochen werden kann und dass es keinen automatischen Rollback gibt (was bei transaktionalen Tabellen immer möglich ist, wenn Sie nicht mit extremer Sorgfalt vorgehen). MySQL Server garantiert außerdem, dass es nicht zur Dirty Reads kommt.

Die folgende Liste erläutert ein paar Methoden für die Arbeit mit nichttransaktionalen Tabellen:

Gespeicherte Prozeduren und Funktionen sind ab MySQL 5.0 implementiert. Siehe auch Kapitel 19, Gespeicherte Prozeduren und Funktionen.

Die grundlegende Trigger-Funktionalität ist ab MySQL 5.0.2 implementiert. Die Weiterentwicklung ist für MySQL 5.1 vorgesehen. Siehe auch Kapitel 20, Trigger.

Ab MySQL Server 3.23.44 unterstützt die InnoDB-Speicher-Engine die Überprüfung von Fremdschlüsselbeschränkungen einschließlich CASCADE, ON DELETE und ON UPDATE. Siehe auch Abschnitt 14.2.6.4, „Fremdschlüssel-Beschränkungen“.

Bei anderen Speicher-Engines als InnoDB verarbeitet MySQL Server zwar die FOREIGN KEY-Syntax in CREATE TABLE-Anweisungen, verwendet oder speichert sie aber nicht. Zukünftig wird die Implementierung auf die Speicherung dieser Information in der Tabellenspezifikationsdatei erweitert, sodass sie mit mysqldump und ODBC abgerufen werden kann. Zu einem späteren Zeitpunkt werden Fremdschlüsselbeschränkungen auch für MyISAM-Tabellen implementiert werden.

Die Durchsetzung von Fremdschlüsseln bietet Datenbankentwicklern verschiedene Vorteile:

Denken Sie in jedem Fall daran, dass diese Vorteile auf Kosten einer zusätzlichen Belastung des Datenbankservers entstehen, da dieser die erforderlichen Überprüfungen durchführen muss. Weitere Überprüfungen durch den Server beeinträchtigen die Leistungsfähigkeit in so hohem Maße, dass sie für bestimmte Anwendungen vermieden werden sollten, sofern dies möglich ist. (Aus diesem Grund ist die Fremdschlüssellogik bei einigen größeren kommerziellen Anwendungen auch auf Anwendungsebene programmiert.)

MySQL stellt Datenbankprogrammierern die Auswahl des zu verwendenden Ansatzes frei. Wenn Sie keine Fremdschlüssel benötigen und die Mehrbelastung des Servers bei der Durchsetzung der referenziellen Integrität vermeiden wollen, können Sie stattdessen eine andere Speicher-Engine wie etwa MyISAM auswählen. (Die MyISAM-Engine bietet eine sehr gute Performance für Anwendungen, die nur INSERT- und SELECT-Operationen durchführen. In solchen Fällen weist die Tabelle keine Löcher in der Mitte auf, und das Einfügen und Abrufen von Daten kann gleichzeitig erfolgen. Siehe auch Abschnitt 7.3.2, „Themen, die Tabellensperren betreffen“.)

Wenn Sie sich dafür entscheiden, die Vorteile der Überprüfung der referenziellen Integrität nicht zu nutzen, dann sollten Sie die folgenden Gesichtspunkte in Ihre Überlegungen mit einbeziehen:

Denken Sie daran, dass der Einsatz von Fremdschlüsseln unter Umständen zu Problemen führen kann:

Beachten Sie, dass Fremdschlüssel in SQL zur Überprüfung und Durchsetzung der referenziellen Integrität verwendet werden, nicht jedoch zur Verknüpfung von Tabellen. Wenn Sie mit einer SELECT-Abfrage Ergebnisse aus mehreren Tabellen abrufen wollen, tun Sie dies mithilfe eines Joins dieser Tabellen:

SELECT * FROM t1, t2 WHERE t1.id = t2.id;

Siehe auch Abschnitt 13.2.7.1, „JOIN“, und Abschnitt 3.6.6, „Wie Fremdschlüssel verwendet werden“.

Die FOREIGN KEY-Syntax ohne ON DELETE ... wird von ODBC-Anwendungen häufig zur Erzeugung automatischer WHERE-Klauseln verwendet.

Views (einschließlich aktualisierbarer Views) sind ab MySQL Server 5.0.1 implementiert. Siehe auch Kapitel 21, Views.

Views sind praktisch, wenn es darum geht, Benutzern den Zugriff auf einen Satz von Beziehungen (Tabellen) so zu gestatten, als ob es sich nur um eine einzige Tabelle handeln würde, und ihren Zugriff auf diesen Satz zu beschränken. Views können auch zur Beschränkung des Zugriffs auf Datensätze (d. h. auf eine Teilmenge einer bestimmten Tabelle) verwendet werden. Für die Steuerung des Spaltenzugriffs können Sie auch das pfiffige Berechtigungssystem in MySQL Server benutzen. Siehe auch Abschnitt 5.8, „Allgemeine Sicherheitsaspekte und das MySQL-Zugriffsberechtigungssystem“.

Bei der Entwicklung der Views-Implementierung war und ist es unser ehrgeiziges Ziel, in den Grenzen von SQL eine möglichst vollständige Konformität mit „Codds Regel Nr. 6“ für relationale Datenbanksysteme zu erzielen, die da besagt: „Alle Views, die theoretisch aktualisierbar sind, sollten auch in der Praxis aktualisierbar sein“.

Standard-SQL verwendet die C-Syntax /* This is a Comment */ für Kommentare, und auch MySQL Server unterstützt diese Syntax. Ferner unterstützt MySQL Erweiterungen dieser Syntax, die die Einbettung MySQL-spezifischen SQL-Codes in den Kommentar gestatten. Siehe auch Abschnitt 9.4, „Kommentar“.

Als Startkommentarsequenz benutzt Standard-SQL ‘--’. MySQL Server setzt hingegen ‘#’ als Startkommentarzeichen. MySQL Server 3.23.3 und höher unterstützen zudem eine Variante des Kommentarstils ‘--’. Das bedeutet, dass der Startkommentarsequenz ‘--’ ein Leerzeichen (oder ein Steuerzeichen wie etwa der Zeilenwechsel) folgen muss. Das Leerzeichen ist erforderlich, um Probleme mit automatisch erzeugten SQL-Abfragen zu vermeiden, die Konstrukte wie das folgende verwenden, in dem wir in !payment! automatisch eine Rechnungssumme einsetzen:

UPDATE account SET credit=credit-!payment!

Überlegen Sie einmal, was passieren würde, wenn payment einen negativen Wert wie etwa -1 hätte:

UPDATE account SET credit=credit--1

credit--1 ist in SQL ein zulässiger Ausdruck, aber ‘--’ wird als Start eines Kommentars interpretiert – ein Teil des Ausdrucks wird also verworfen! Das Ergebnis ist eine Anweisung, die eine vollständig andere Bedeutung hat als ursprünglich vorgesehen:

UPDATE account SET credit=credit

Diese Anweisung erzeugt überhaupt keine Werteänderung! So lässt sich veranschaulichen, dass es erhebliche Folgen haben könnte, wenn man ‘--’ als Startkommentarsequenz zulassen würde.

Wenn man unsere in MySQL 3.23.3 und höher vorhandene Implementierung verwendet, bei der auf ‘--’ zwingend ein Leerzeichen folgen muss, damit die Startkommentarsequenz als solche erkannt wird, ist credit--1 tatsächlich sicher.

Eine weiteres Sicherheitsmerkmal besteht darin, dass der Befehlszeilenclient mysql Zeilen ignoriert, die mit ‘--’ beginnen.

Die nachfolgenden Informationen sind nur von Bedeutung, wenn Sie eine MySQL-Version vor 3.23.3 verwenden:

Wenn Sie ein SQL-Skript, das Kommentare des Typs ‘--’ enthält, als Textdatei gespeichert haben, dann sollten Sie das Utility replace wie folgt verwenden, um die Kommentare so umzuwandeln, dass Sie das Zeichen ‘#’ verwenden, bevor Sie das Skript ausführen:

shell> replace " --" " #" < text-file-with-funny-comments.sql \
         | mysql db_name

Dies ist sicherer, als das Skript auf übliche Weise auszuführen:

shell> mysql db_name < text-file-with-funny-comments.sql

Sie können die Skriptdatei auch „an Ort und Stelle“ bearbeiten, damit die Kommentare des Typs ‘--’ in ‘#’-Kommentare umgewandelt werden:

shell> replace " --" " #" -- text-file-with-funny-comments.sql

Mit folgendem Befehl machen Sie die Änderung rückgängig:

shell> replace " #" " --" -- text-file-with-funny-comments.sql

Siehe auch Abschnitt 8.17, „replace — Hilfsprogramm für String-Ersetzungen“.

Normalerweise tritt ein Fehler auf, wenn Sie versuchen, einen Datensatz mit INSERT bzw. UPDATE einzufügen oder zu aktualisieren, und dadurch eine Unvereinbarkeit bezüglich eines Primärschlüssels, eines eindeutigen Schlüssels oder eines Fremdschlüssels erfolgen würde. Verwenden Sie eine transaktionale Speicher-Engine wie InnoDB, dann macht MySQL die Anweisung automatisch rückgängig. Nutzen Sie hingegen eine nichttransaktionale Speicher-Engine, dann beendet MySQL die Verarbeitung der Anweisung bei dem Datensatz, an dem der Fehler aufgetreten ist, und lässt alle nachfolgenden Datensätze unverändert.

Für den Fall, dass Sie solche Unvereinbarkeiten ignorieren wollen, unterstützt MySQL das Schlüsselwort IGNORE für INSERT und UPDATE. In diesem Fall ignoriert MySQL sämtliche Schlüsselunvereinbarkeiten und fährt mit der Verarbeitung des nächsten Datensatzes fort. Siehe auch Abschnitt 13.2.4, „INSERT“, und Abschnitt 13.2.10, „UPDATE“.

Informationen zur Anzahl der tatsächlich eingefügten oder aktualisierten Datensätze erhalten Sie über die C-API-Funktion mysql_info(). Ab MySQL 4.1 können Sie auch die Anweisung SHOW WARNINGS verwenden. Siehe auch Abschnitt 24.2.3.34, „mysql_info()“, und Abschnitt 13.5.4.25, „SHOW WARNINGS“.

Derzeit unterstützen nur InnoDB-Tabellen Fremdschlüssel. Siehe auch Abschnitt 14.2.6.4, „Fremdschlüssel-Beschränkungen“. Die Fremdschlüsselunterstützung in MyISAM-Tabellen ist zur Implementierung in MySQL 5.2 vorgesehen. Siehe auch Abschnitt 1.6, „MySQL-Roadmap“.

Vor MySQL 5.0.2 verzeiht MySQL unzulässige oder unzutreffende Dateneingaben und setzt diese nach der Eingabe auf zulässige Werte. Bei MySQL 5.0.2 und höher bleibt dies zwar auch das Standardverhalten, aber Sie können den SQL-Modus des Servers so ändern, dass ein traditionellerer Umgang mit solchen Daten gewählt wird: Der Server kann sie dann auch abweisen und die Anweisung abbrechen, in der sie auftreten. Abschnitt 5.2.5, „Der SQL-Modus des Servers“.

Dieser Abschnitt beschreibt das (nachsichtige) Standardverhalten von MySQL und den neueren strikten SQL-Modus sowie die Unterschiede zwischen diesen Modi.

Wenn Sie den strikten Modus nicht verwenden, dann wird, wann immer Sie einen „falschen“ Wert in eine Spalte einsetzen (z. B. eine NULL in eine NOT NULL-Spalte oder einen zu großen numerischen Wert in eine numerische Spalte), MySQL die Spalte auf den „bestmöglichen“ Wert setzen, statt einen Fehler zu erzeugen. Die folgenden Regeln beschreiben genauer, wie dies funktioniert:

Der Grund für die Verwendung obiger Regeln im nicht strikten Modus ist, dass wir diese Bedingungen erst nach Beginn der Ausführung der betreffenden Anweisung überprüfen können. Tritt nach der Aktualisierung einiger Datensätze ein Problem auf, dann können wir nicht einfach einen Rollback durchführen, da die Speicher-Engine Rollbacks unter Umständen nicht unterstützt. Die Option, die Anweisung einfach zu beenden, wäre nachteilig; in diesem Fall wäre die Aktualisierung nämlich nur „zur Hälfte“ erfolgt, was das wohl schlimmste vorstellbare Szenario wäre. In einem solchen Fall ist es besser, das „Bestmögliche“ zu tun und dann fortzufahren, so als ob nichts gewesen wäre.

In MySQL 5.0.2 und höher können Sie eine strengere Behandlung der Eingabewerte mithilfe der SQL-Modi STRICT_TRANS_TABLES oder STRICT_ALL_TABLES auswählen:

SET sql_mode = 'STRICT_TRANS_TABLES';
SET sql_mode = 'STRICT_ALL_TABLES';

STRICT_TRANS_TABLES aktiviert den strikten Modus für transaktionale Speicher-Engines und bis zu einem gewissen Grad auch für nichttransaktionale Engines. Das funktioniert wie folgt:

Für eine noch striktere Prüfung aktivieren Sie STRICT_ALL_TABLES. Dies entspricht weitgehend STRICT_TRANS_TABLES, nur führen Fehler bei nichttransaktionalen Speicher-Engines hier dazu, dass die Anweisung auch bei unzulässigen Daten im zweiten oder allen folgenden Datensätzen abgebrochen wird. Das bedeutet, dass, wenn bei einer nichttransaktionalen Tabelle im Verlauf einer Einfüge- oder Aktualisierungsoperation für mehrere Datensätze ein Fehler auftritt, nur eine Teilaktualisierung erfolgt. Datensätze vor Auftreten des Fehlers werden eingefügt bzw. aktualisiert, Datensätze nach dem Fehler jedoch nicht. Um dieses Verhalten bei nicht transaktionalen Tabellen zu vermeiden, verwenden Sie entweder Anweisungen für einzelne Datensätze oder aber STRICT_TRANS_TABLES, sofern Konvertierungswarnungen (statt Fehlern) akzeptabel sind. Um Probleme bereits im Vorfeld zu vermeiden, sollten Sie zur Überprüfung des Spalteninhalts nicht MySQL verwenden. Es ist sicherer (und oft auch schneller), wenn die Anwendung sicherstellt, dass sie nur zulässige Werte an die Datenbank übermittelt.

Bei Auswahl eines strikten Modus können Sie die Behandlung von Fehlern als Warnungen vorsehen, indem Sie INSERT IGNORE bzw. UPDATE IGNORE statt INSERT oder UPDATE ohne IGNORE verwenden.

ENUM- und SET-Spalten stellen eine effiziente Möglickeit dar, Spalten zu definieren, die nur eine festgelegte Wertemenge aufnehmen können. Siehe auch Abschnitt 11.4.4, „Der Spaltentyp ENUM“, und Abschnitt 11.4.5, „Der Spaltentyp SET“. Allerdings ermöglichen ENUM- und SET-Spalten vor MySQL 5.0.2 keine echten Constraints bei der Eingabe ungültiger Daten:

Ab MySQL 5.0.2 können Sie den Server so konfigurieren, dass er den strikten SQL-Modus verwendet. Siehe auch Abschnitt 5.2.5, „Der SQL-Modus des Servers“. Ist der strikte Modus aktiviert, dann fungiert die Definition einer ENUM- oder SET-Spalte als Beschränkung für Werte, die in die Spalte eingegeben werden. Bei Werten, die die folgenden Bedingungen nicht erfüllen, tritt ein Fehler auf:

Fehler aufgrund ungültiger Werte können im strikten Modus unterdrückt werden, indem Sie INSERT IGNORE bzw. UPDATE IGNORE verwenden. In diesem Fall wird statt eines Fehlers eine Warnung erzeugt. Bei ENUM wird der Wert als Fehlermitglied (0) eingefügt. Bei SET wird der Wert wie vorgegeben eingefügt, sofern nicht vorhandene ungültige Teil-Strings gelöscht werden. So führt etwa 'a,x,b,y' zum Wert 'a,b'.

Die erste zu treffende Entscheidung ist die, ob Sie einen (stabilen) Produktions-Release oder aber einen Entwicklungs-Release verwenden wollen. Im MySQL-Entwicklungsprozess koexistieren mehrere Release-Serien miteinander, die sich alle durch ihren Grad der Ausgereiftheit voneinander unterscheiden:

Wir halten ein endgültiges Einfrieren von Codes nicht für machbar, da dies Bugfixes und andere Fehlerbereinigungen, die erforderlich sind, unmöglich machen würde. Das von uns bevorzugte „Teileinfrieren“ erlaubt uns das Ergänzen von Kleinigkeiten, die sich nicht auf die Einsatzfähigkeit eines Produktions-Releases auswirken sollten. Natürlich pflanzen sich wesentliche Bugfixes in früheren Serien auch auf ihre jeweiligen Nachfolger fort.

Wenn Sie MySQL zum ersten Mal verwenden oder es auf ein System portieren wollen, für das keine binäre Distribution verfügbar ist, empfehlen wir Ihnen normalerweise, die Produktions-Release-Serie zu verwenden. Derzeit ist dies MySQL 5.0. Alle MySQL-Releases – auch die der Entwicklungsserie – werden vor der Veröffentlichung mit den MySQL-Benchmarks und der umfangreichen Testsuite überprüft.

Wenn Sie ein älteres System verwenden und ein Upgrade durchzuführen beabsichtigen, gleichzeitig aber verhindern wollen, dass es während der Aktualisierung zu Problemen kommt, dann sollten Sie auf die aktuelle Version derselben Release-Serie aktualisieren, die Sie bereits verwenden (hierbei ist nur der letzte Teil der Versionsnummer höher als bei der von Ihnen verwendeten Version). Wir haben lediglich versucht, kritische Bugs zu beheben und kleine, relativ „sichere“ Änderungen an dieser Version vorzunehmen.

Wenn Sie neue Funktionen verwenden wollen, die nicht in der Produktions-Release-Serie vorhanden sind, können Sie sich auch für eine Version aus der Entwicklungsserie entscheiden. Beachten Sie, dass die Entwicklungs-Releases nicht so stabil sind wie die Produktions-Releases.

Wollen Sie die allerneuesten Quellcodes mit allen aktuellen Patches und Bugfixes einsetzen, dann können Sie eines unserer BitKeeper-Repositorys verwenden. Dies sind nicht „Releases“ im eigentlichen Sinne, sondern Vorabversionen des Codes, auf dem zukünftige Releases basieren werden.

Das MySQL-Benennungsschema verwendet Release-Namen, die aus drei Zahlen und einem Suffix bestehen. Dies kann etwa so aussehen: mysql-5.0.12-beta. Die Zahlen im Release-Namen sind wie folgt zu interpretieren:

Bei kleineren Updates wird jeweils die letzte Zahl im Versions-String hochgezählt. Liegen wesentliche Neuerungen bei den Merkmalen oder kleinere Inkompatibilitäten mit vorherigen Versionen vor, dann wird die zweite Zahl im Versions-String hochgezählt. Ändert sich schließlich das Dateiformat, dann wird die erste Zahl erhöht.

Release-Namen enthalten auch ein Suffix, welches die Stabilitätsstufe für den Release angibt. Releases innerhalb einer Serie durchschritten eine bestimmte Abfolge von Suffixen, die jeweils anzeigen, wie sich die Stabilität erhöht. Mögliche Suffixe sind die folgenden:

MySQL verwendet ein Benennungsschema, welches sich geringfügig von dem anderer Produkte unterscheidet. In der Regel können Sie problemlos jede Version einsetzen, die bereits seit ein paar Wochen verfügbar ist, ohne durch eine neue Version innerhalb derselben Release-Serie ersetzt worden zu sein.

Alle MySQL-Releases werden mit unseren Standardtests und Benchmarks überprüft, damit gewährleistet ist, dass ihr Einsatz relativ sicher ist. Da die Standardtests im Laufe der Zeit so erweitert werden, dass alle zuvor gefundenen Bugs berücksichtigt werden, wird unsere Testsuite immer besser.

Alle Releases wurden zumindest mit den folgenden Tools getestet:

Wir testen außerdem die neueste MySQL-Version immer auf zumindest einem System in unserer internen Produktionsumgebung. Dabei stehen uns mehr als 100 Gbyte Daten zum Arbeiten zur Verfügung.

Nachdem Sie die zu installierende MySQL-Version gewählt haben, müssen Sie noch festlegen, ob eine binäre oder eine Quelldistribution für die Installation verwendet werden soll. In den meisten Fällen werden Sie sich wahrscheinlich für die Binärdistribution entscheiden, sofern es für Ihre Plattform eine solche gibt. Binärdistributionen sind für viele Plattformen im nativen Format verfügbar, z. B. RPM-Dateien für Linux oder DMG-Pakete für Mac OS X. Distributionen sind außerdem als ZIP-Archive oder komprimierte tar-Dateien erhältlich.

Die folgenden Gründe sprechen für die Verwendung einer Binärdistribution:

Unter bestimmten Umständen kann es auch von Vorteil sein, MySQL aus einer Quelldistribution heraus zu installieren:

MySQL entwickelt sich ziemlich schnell, und neue Entwicklungen wollen wir anderen MySQL-Benutzern möglichst umgehend bereitstellen. Deswegen erstellen wir immer dann einen neuen Release, wenn wir neue und nützliche Funktionen integriert haben, die auch für andere Benutzer nützlich oder notwendig sein könnten.

Außerdem versuchen wir Benutzern zu helfen, die nach Funktionen fragen, welche leicht zu implementieren sind. Wir achten darauf, was unsere lizenzierten Benutzer – und insbesondere die Kunden unseres Supports – wollen, und versuchen ihnen in dieser Hinsicht zu helfen.

Niemand ist gezwungen, einen neuen Release herunterzuladen. Der Abschnitt „News“ soll Ihnen dabei helfen zu ermitteln, ob im neuen Release etwas dabei ist, was Sie wirklich brauchen. Siehe auch Anhang D, MySQL-Änderungsverlauf (Change History).

Bei der Aktualisierung von MySQL halten wir uns an die folgenden Richtlinien:

Wir verwenden viel Zeit und Mühe darauf, unsere Releases fehlerfrei zu machen. Bislang haben wir nicht eine einzige MySQL-Version veröffentlicht, die einen bekannten nachvollziehbaren schweren Bug aufwies (ein „schwerer“ Bug ist ein Umstand, der dazu führt, dass MySQL bei normaler Verwendung abstürzt, falsche Antworten für normale Abfragen erzeugt oder ein Sicherheitsproblem aufweist).

Wir haben alle offenen Probleme, Bugs und Streitfragen dokumentiert, die von strukturellen Entscheidungen abhängen. Siehe auch Abschnitt A.8, „Bekannte Fehler und konzeptionelle Unzulänglichkeiten in MySQL“.

Unser Ziel ist es, alle Bugs zu beheben, die behebbar sind, ohne eine stabile MySQL-Version weniger stabil machen zu müssen. In bestimmten Fällen bedeutet dies, dass wir ein Problem in den Entwicklungsversionen, nicht aber in der stabilen Produktionsversion beheben können. Natürlich dokumentieren wir solche Probleme, damit sie den Benutzern bekannt sind.

Es folgt eine Beschreibung unserer Vorgehensweise:

Eine der Dienstleistungen von MySQL AB besteht in der Bereitstellung von MySQL-Binärdistributionen, die entweder auf unseren eigenen Systemen oder aber auf Systemen kompiliert wurden, bei denen uns Unterstützer von MySQL freundlicherweise Zugang zu ihren Computern gewährt haben.

Neben den Binärdateien in den plattformspezifischen Paketformaten bieten wir für eine Anzahl von Plattformen auch Binärdistributionen in Form komprimierter tar-Dateien (.tar.gz-Dateien) an. Siehe auch Abschnitt 2.2, „Schnelle Standardinstallation von MySQL“.

Die RPM-Distributionen für MySQL 5.1-Releases, die wir über die Website bereitstellen, werden von MySQL AB angefertigt.

Informationen zu Windows-Distributionen finden Sie in Abschnitt 2.3, „Installation von MySQL unter Windows“.

Diese Distributionen werden mithilfe des Skripts Build-tools/Do-compile erzeugt, das den Quellcode kompiliert und das Binärarchiv tar.gz mithilfe von scripts/make_binary_distribution erstellt.

Diese Binärdateien werden mit den folgenden Compilern und Optionen konfiguriert und erstellt. Diese Informationen können Sie auch abrufen, indem Sie die Variablen COMP_ENV_INFO und CONFIGURE_LINE im Skript bin/mysqlbug jeder tar-Binärdistributionsdatei abfragen.

Sollten Sie optimalere Optionen für einen der folgenden configure-Befehle haben, dann schicken Sie diese an die MySQL-Mailingliste internals. Siehe auch Abschnitt 1.7.1, „Die MySQL-Mailinglisten“.

Wollen Sie eine Debugversion von MySQL kompilieren, dann sollten Sie die Option--with-debug oder --with-debug=full zu den folgenden configure-Befehlen hinzufügen und ggf. vorhandene -fomit-frame-pointer-Optionen entfernen.

Die folgenden Binärdateien werden auf den Entwicklungssystemen von MySQL AB erstellt:

Die folgenden Binärdistributionen wurden auf Systemen von Dritten erstellt, die MySQL AB freundlicherweise von anderen Benutzern zur Verfügung gestellt wurden. Diese werden aus Gefälligkeit bereitgestellt; MySQL AB hat keine vollständige Kontrolle über diese Systeme, weswegen wir für Binärdistributionen, die auf ihnen erstellt wurden, nur eingeschränkten Support bieten können.

Die folgenden Kompilierungsoptionen wurden für Binärpakete verwendet, die MySQL AB in der Vergangenheit bereitgestellt hat. Diese Binärdistributionen werden nicht mehr aktualisiert. Die Kompilierungsoptionen werden zu Referenzzwecken an diese Stelle aufgelistet.

Wenn Sie ein MySQL-Paket heruntergeladen haben, sollten Sie sicherstellen, dass die zugehörige MD5-Prüfsumme mit der auf den MySQL-Downloadseiten angegebenen Prüfsumme übereinstimmt. Jedes Paket weist eine individuelle Prüfsumme auf, die Sie mithilfe des folgenden Befehls abfragen können (hierbei ist package_name der Name des heruntergeladenen Pakets):

shell> md5sum package_name

Beispiel:

shell> md5sum mysql-standard-5.1.5-alpha-linux-i686.tar.gz
aaab65abbec64d5e907dcd41b8699945  mysql-standard-5.1.5-alpha-linux-i686.tar.gz

Vergewissern Sie sich, dass die resultierende Prüfsumme (der angezeigte Hexadezimal-String) mit der Angabe übereinstimmt, die auf der Downloadseite unmittelbar unter dem betreffenden Paket angegeben ist.

Hinweis: Sie müssen die Prüfsumme der Archivdatei (d. h. der .zip- oder .tar.gz-Datei) verifizieren, nicht die Prüfsumme der Dateien, die im Archiv gespeichert sind.

Beachten Sie, dass nicht alle Betriebssysteme den Befehl md5sum unterstützen. Bei manchen heißt er einfach md5, bei anderen ist er überhaupt nicht enthalten. Bei Linux ist er Teil des Pakets GNU Text Utilities, das für eine Vielzahl von Plattformen verfügbar ist. Sie können den Quellcode auch unter http://www.gnu.org/software/textutils/ herunterladen. Wenn Sie OpenSSL installiert haben, können Sie stattdessen den Befehl openssl md5 package_name verwenden. Eine Windows-Implementierung des Befehls md5 ist unter http://www.fourmilab.ch/md5/ verfügbar. winMd5Sum ist ein grafisches MD5-Prüfwerkzeug, das Sie sich unter http://www.nullriver.com/index/products/winmd5sum beschaffen können.

Eine andere Methode zur Überprüfung der Integrität und Authentizität eines Pakets besteht in der Verwendung kryptografischer Signaturen. Diese sind zuverlässiger, aber arbeitsaufwändiger als MD5-Prüfsummen.

Wir von MySQL AB signieren MySQL-Pakete für den Download mit GnuPG (GNU Privacy Guard). GnuPG ist eine Open-Source-Alternative zum bekannten Pretty Good Privacy (PGP) von Phil Zimmermann. Weitere Informationen zu GnuPG sowie zu dessen Download und Installation auf Ihrem System finden Sie unter http://www.gnupg.org/. Die meisten Linux-Distributionen werden mit standardmäßig installiertem GnuPG ausgeliefert. Weitere Informationen zu GnuPG finden Sie unter http://www.openpgp.org/.

Um die Signatur für ein bestimmtes Paket zu überprüfen, müssen Sie sich zunächst eine Kopie des GPG-Build-Schlüssels von MySQL AB beschaffen. Diese können Sie unter http://www.keyserver.net/ herunterladen. Der erforderliche Schlüssel heißt build@mysql.com. Alternativ können Sie den Schlüssel aus dem folgenden Text kopieren und direkt einfügen:

Key ID:
pub  1024D/5072E1F5 2003-02-03
     MySQL Package signing key (www.mysql.com) <build@mysql.com>
Fingerprint: A4A9 4068 76FC BD3C 4567  70C8 8C71 8D3B 5072 E1F5

Public Key (ASCII-armored):

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

mQGiBD4+owwRBAC14GIfUfCyEDSIePvEW3SAFUdJBtoQHH/nJKZyQT7h9bPlUWC3
RODjQReyCITRrdwyrKUGku2FmeVGwn2u2WmDMNABLnpprWPkBdCk96+OmSLN9brZ
fw2vOUgCmYv2hW0hyDHuvYlQA/BThQoADgj8AW6/0Lo7V1W9/8VuHP0gQwCgvzV3
BqOxRznNCRCRxAuAuVztHRcEAJooQK1+iSiunZMYD1WufeXfshc57S/+yeJkegNW
hxwR9pRWVArNYJdDRT+rf2RUe3vpquKNQU/hnEIUHJRQqYHo8gTxvxXNQc7fJYLV
K2HtkrPbP72vwsEKMYhhr0eKCbtLGfls9krjJ6sBgACyP/Vb7hiPwxh6rDZ7ITnE
kYpXBACmWpP8NJTkamEnPCia2ZoOHODANwpUkP43I7jsDmgtobZX9qnrAXw+uNDI
QJEXM6FSbi0LLtZciNlYsafwAPEOMDKpMqAK6IyisNtPvaLd8lH0bPAnWqcyefep
rv0sxxqUEMcM3o7wwgfN83POkDasDbs3pjwPhxvhz6//62zQJ7Q7TXlTUUwgUGFj
a2FnZSBzaWduaW5nIGtleSAod3d3Lm15c3FsLmNvbSkgPGJ1aWxkQG15c3FsLmNv
bT6IXQQTEQIAHQUCPj6jDAUJCWYBgAULBwoDBAMVAwIDFgIBAheAAAoJEIxxjTtQ
cuH1cY4AnilUwTXn8MatQOiG0a/bPxrvK/gCAJ4oinSNZRYTnblChwFaazt7PF3q
zIhMBBMRAgAMBQI+PqPRBYMJZgC7AAoJEElQ4SqycpHyJOEAn1mxHijft00bKXvu
cSo/pECUmppiAJ41M9MRVj5VcdH/KN/KjRtW6tHFPYhMBBMRAgAMBQI+QoIDBYMJ
YiKJAAoJELb1zU3GuiQ/lpEAoIhpp6BozKI8p6eaabzF5MlJH58pAKCu/ROofK8J
Eg2aLos+5zEYrB/LsrkCDQQ+PqMdEAgA7+GJfxbMdY4wslPnjH9rF4N2qfWsEN/l
xaZoJYc3a6M02WCnHl6ahT2/tBK2w1QI4YFteR47gCvtgb6O1JHffOo2HfLmRDRi
Rjd1DTCHqeyX7CHhcghj/dNRlW2Z0l5QFEcmV9U0Vhp3aFfWC4Ujfs3LU+hkAWzE
7zaD5cH9J7yv/6xuZVw411x0h4UqsTcWMu0iM1BzELqX1DY7LwoPEb/O9Rkbf4fm
Le11EzIaCa4PqARXQZc4dhSinMt6K3X4BrRsKTfozBu74F47D8Ilbf5vSYHbuE5p
/1oIDznkg/p8kW+3FxuWrycciqFTcNz215yyX39LXFnlLzKUb/F5GwADBQf+Lwqq
a8CGrRfsOAJxim63CHfty5mUc5rUSnTslGYEIOCR1BeQauyPZbPDsDD9MZ1ZaSaf
anFvwFG6Llx9xkU7tzq+vKLoWkm4u5xf3vn55VjnSd1aQ9eQnUcXiL4cnBGoTbOW
I39EcyzgslzBdC++MPjcQTcA7p6JUVsP6oAB3FQWg54tuUo0Ec8bsM8b3Ev42Lmu
QT5NdKHGwHsXTPtl0klk4bQk4OajHsiy1BMahpT27jWjJlMiJc+IWJ0mghkKHt92
6s/ymfdf5HkdQ1cyvsz5tryVI3Fx78XeSYfQvuuwqp2H139pXGEkg0n6KdUOetdZ
Whe70YGNPw1yjWJT1IhMBBgRAgAMBQI+PqMdBQkJZgGAAAoJEIxxjTtQcuH17p4A
n3r1QpVC9yhnW2cSAjq+kr72GX0eAJ4295kl6NxYEuFApmr1+0uUq/SlsQ==
=YJkx
-----END PGP PUBLIC KEY BLOCK-----

Um den Schlüssel in Ihren eigenen öffentlichen GPG-Schlüsselbund zu importieren, verwenden Sie gpg --import. Haben Sie den Schlüssel beispielsweise unter dem Dateinamen mysql_pubkey.asc gespeichert, dann sieht der Importbefehl wie folgt aus:

shell> gpg --import mysql_pubkey.asc

Nachdem Sie den öffentlichen Schlüssel heruntergeladen und importiert haben, laden Sie das gewünschte MySQL-Paket und die entsprechende Signatur herunter (diese steht ebenfalls auf der Downloadseite zur Verfügung). Die Signaturdatei hat den gleichen Namen wie die Distributionsdatei und trägt die Erweiterung .asc. Ein Beispiel:

Stellen Sie sicher, dass beide Dateien im gleichen Verzeichnis gespeichert sind, und führen Sie dann den folgenden Befehl aus, um die Signatur der Distributionsdatei zu verifizieren:

shell> gpg --verify package_name.asc

Beispiel:

shell> gpg --verify mysql-standard-5.1.5-alpha-linux-i686.tar.gz.asc
gpg: Signature made Tue 12 Jul 2005 23:35:41 EST using DSA key ID 5072E1F5
gpg: Good signature from "MySQL Package signing key (www.mysql.com) <build@mysql.com>"

Die Meldung Good signature (Signatur korrekt) zeigt an, dass alles in Ordnung ist. Sie können alle Warnungen vom Typ insecure memory ignorieren, die unter Umständen angezeigt werden.

Weitere Informationen zum Umgang mit öffentlichen Schlüsseln finden Sie in der GPG-Dokumentation.

Bei RPM-Paketen ist keine separate Signatur vorhanden. RPM-Pakete enthalten vielmehr eine integrierte GPG-Signatur und eine MD5-Prüfsumme. Sie können ein Paket durch Ausführen des folgenden Befehls verifizieren:

shell> rpm --checksig package_name.rpm

Beispiel:

shell> rpm --checksig MySQL-server-5.1.5-alpha-0.i386.rpm
MySQL-server-5.1.5-alpha-0.i386.rpm: md5 gpg OK

Hinweis: Wenn Sie RPM 4.1 verwenden und die Meldung (GPG) NOT OK (MISSING KEYS: GPG#5072e1f5) erhalten, obwohl Sie den öffentlichen MySQL-Schlüssel zuerst in Ihren eigenen GPG-Schlüsselbund importiert haben, dann müssen Sie den Schlüssel zuerst in Ihren RPM-Schlüsselbund importieren. RPM 4.1 verwendet nicht länger den GPG-Schlüsselbund (oder GPG selbst). Stattdessen arbeitet es mit einem eigenen Schlüsselbund, da es eine systemweite Anwendung ist, während der öffentliche GPG-Schlüsselbund eine benutzerspezifische Datei ist. Um den öffentlichen MySQL-Schlüssel in den RPM-Schlüsselbund zu importieren, besorgen Sie sich den Schlüssel zunächst wie in Abschnitt 2.1.4.2, „Signaturüberprüfung mit GnuPG“, beschrieben. Nachfolgend verwenden Sie den Befehl rpm --import für den Schlüsselimport. Haben Sie den öffentlichen Schlüssel beispielsweise unter dem Dateinamen mysql_pubkey.asc gespeichert, dann sieht der Importbefehl wie folgt aus:

shell> rpm --import mysql_pubkey.asc

Wie Sie sich den öffentlichen MySQL-Schlüssel beschaffen, lesen Sie in Abschnitt 2.1.4.2, „Signaturüberprüfung mit GnuPG“.

Der MySQL-Installations-Assistent ist ein Installationsprogramm für den MySQL Server, das die aktuellen Installer-Technologien von Microsoft Windows nutzt. In Verbindung mit dem MySQL-Konfigurations-Assistenten ermöglicht der MySQL-Installations-Assistent einem Benutzer die Installation und Konfiguration eines MySQL Servers, der direkt nach der Installation einsatzbereit ist.

Der MySQL-Installations-Assistent ist das Standardinstallationsprogramm für alle MySQL Server-Distributionen ab Version 4.1.5. Benutzer vorheriger MySQL-Versionen müssen ihre vorhandenen MySQL-Installationen manuell herunterfahren und entfernen, bevor sie MySQL mit dem MySQL-Installations-Assistenten installieren. In Abschnitt 2.3.4.7, „Upgrade von MySQL mit dem Installations-Assistenten“, finden Sie weitere Informationen zur Aktualisierung einer früheren Version.

In den aktuellen Windows-Versionen hat Microsoft eine verbesserte Version von MSI (Microsoft Windows Installer) implementiert. In Windows 2000, Windows XP und Windows Server 2003 ist MSI der De-facto-Standard für die Anwendungsinstallation. Der MySQL-Installations-Assistent nutzt diese Technologie, um den Installationsprozess reibungsloser und flexibler zu gestalten.

Die MSI-Engine wurde mit der Veröffentlichung von Windows XP aktualisiert. Wenn Sie eine vorherige Windows-Version einsetzen, finden Sie in dem Microsoft Knowledge Base-Artikel unter der Adresse http://support.microsoft.com/default.aspx?scid=kb;EN-US;292539 Informationen zum Upgrade auf die aktuelle Version der MSI-Engine.

Ferner hat Microsoft kürzlich das WiX-Toolkit (Windows Installer XML) vorgestellt. Hierbei handelt es sich um das erste offizielle Open-Source-Projekt von Microsoft. Wir verwenden WiX nun auch, denn erstens ist es ein Open-Source-Projekt, und zweitens gestattet es die Handhabung des gesamten Windows-Installationsvorgangs auf flexible Weise unter Verwendung von Skripten.

Die Optimierung des MySQL-Installations-Assistenten steht und fällt mit der Unterstützung und dem Feedback solcher Benutzer wie Ihnen. Wenn Sie feststellen, dass im MySQL-Installations-Assistenten etwas fehlt, das für Sie sehr wichtig wäre, oder einen Bug entdecken, melden Sie dies bitte in unserer Bugdatenbank. Hinweise hierzu finden Sie in Abschnitt 1.8, „Wie man Bugs oder Probleme meldet“.

Die MySQL-Installationspakete können unter http://dev.mysql.com/downloads/ heruntergeladen werden. Wenn das von Ihnen heruntergeladene Paket in einem ZIP-Archiv gespeichert ist, müssen Sie dieses zunächst entpacken.

Der Vorgang zum Starten des Assistenten hängt vom Inhalt des heruntergeladenen Installationspakets ab. Enthält dieses eine Datei namens setup.exe, dann doppelklicken Sie darauf, um den Installationsvorgang zu starten. Enthält das Paket hingegen eine .msi-Datei, dann doppelklicken Sie darauf, um den Installationsvorgang zu starten.

Es sind drei Installationstypen vorhanden: Typical (Standard), Complete (Vollständig) und Custom (Benutzerdefiniert).

Bei der Installationsmethode Typical werden der MySQL Server, der Befehlszeilenclient mysql und die befehlszeilenbasierten Hilfsprogramme installiert. Zu den Befehlszeilenclients und Hilfsprogrammen gehören mysqldump, myisamchk und verschiedene weitere Programme zur Verwaltung des MySQL Servers.

Die Installationsmethode Complete installiert alle Komponenten, die im Installationspaket enthalten sind. Das vollständige Installationspaket umfasst Komponenten wie die eingebettete Serverbibliothek, die Benchmark-Reihe, Support-Skripten und die Dokumentation.

Bei der Installationsmethode Custom haben Sie vollständige Kontrolle darüber, welche Pakete installiert werden und wie der Installationspfad aussieht. Weitere Informationen zur benutzerdefinierten Installation finden Sie unter Abschnitt 2.3.4.4, „Der Dialog zur benutzerspezifischen Installation“.

Wenn Sie sich für die Installationsmethode Typical oder Complete entschieden haben und auf die Schaltfläche Next klicken, wird ein Fenster angezeigt, in dem Sie die gewählten Optionen überprüfen und die Installation dann starten können. Wenn Sie hingegen die Methode Custom auswählen und dann auf die Schaltfläche Next klicken, wird nachfolgend das Dialogfeld für die benutzerdefinierte Installation aufgerufen, welches in Abschnitt 2.3.4.4, „Der Dialog zur benutzerspezifischen Installation“, beschrieben wird.

Wenn Sie den Installationspfad oder bestimmte Komponenten ändern wollen, die vom MySQL-Installations-Assistenten installiert werden, wählen Sie die Installationsmethode Custom.

Alle verfügbaren Komponenten werden dann in einer Baumstruktur links im Installationsdialog angezeigt. Komponenten, die nicht installiert werden, sind durch ein rotes X gekennzeichnet, während für die Installation gewählten Komponenten ein graues Symbol aufweisen. Um den Installationsstatus einer Komponente umzuschalten, klicken Sie auf das Symbol der betreffenden Komponente und wählen die gewünschte Option aus der erscheinenden Dropdown-Liste.

Sie können den vorgegebenen Installationspfad ändern, indem Sie auf die Schaltfläche Change... rechts neben dem angezeigten Installationspfad klicken.

Wenn Sie die zu installierenden Komponenten und den Pfad gewählt haben, klicken Sie auf die Schaltfläche Next, um den Bestätigungsdialog anzuzeigen.

Wenn Sie eine Installationsmethode und ggf. die zu installierenden Komponenten gewählt haben, schreiten Sie fort zum Bestätigungsdialog. Installationsmethode und Pfad werden nun zur Bestätigung angezeigt.

Wenn die angezeigten Einstellungen korrekt sind, klicken Sie auf die Schaltfläche Install, um MySQL zu installieren. Wenn Sie Ihre Einstellungen noch einmal ändern wollen, klicken Sie auf die Schaltfläche Back. Um den MySQL-Installations-Assistenten zu verlassen, ohne MySQL zu installieren, klicken Sie auf die Schaltfläche Cancel.

Wenn die Installation abgeschlossen ist, können Sie sich auf der MySQL-Website registrieren. Wenn Sie registriert sind, können Sie Mitteilungen an die MySQL-Foren unter forums.mysql.com schicken, Bugs unter bugs.mysql.com melden und unseren Newsletter abonnieren. Der Abschlussbildschirm des Installationsprogramms zeigt eine Zusammenfassung der Installation und erlaubt Ihnen den Aufruf des MySQL-Konfigurations-Assistenten, mit dem Sie eine Konfigurationsdatei erstellen, den MySQL-Dienst installieren und die Sicherheitseinstellungen konfigurieren können.

Wenn Sie auf die Schaltfläche Install klicken, startet der MySQL-Installations-Assistent den Installationsvorgang und nimmt bestimmte Änderungen an Ihrem System vor, die in den nachfolgenden Abschnitten beschrieben sind.

Änderungen in der Registrierung

Der MySQL-Installations-Assistent erstellt bei Auswahl der Standardinstallation einen Schlüssel in der Windows-Registrierung. Dieser befindet sich unter HKEY_LOCAL_MACHINE\SOFTWARE\MySQL AB.

Der MySQL-Installations-Assistent richtet einen Schlüssel ein, der nach der Hauptversion des installierten Servers benannt ist (z. B. MySQL Server 5.1). Dieser enthält zwei Zeichenfolgenwerte namens Location und Version. Die Zeichenfolge Location enthält den Pfad zum Installationsverzeichnis. Bei einer Standardinstallation heißt der Wert C:\Programme\MySQL\MySQL Server 5.1\. Die Zeichenfolge Version enthält die Release-Nummer. Wird etwa MySQL Server 5.1.5-alpha installiert, dann enthält der Schlüssel den Wert 5.1.5-alpha.

Diese Registrierungsschlüssel ermöglichen es externen Programmen, das Installationsverzeichnis des MySQL Servers zu ermitteln; hierdurch wird eine zeitaufwändige vollständige Durchsuchung der Festplatte zur Ermittlung des Installationspfads des MySQL Servers unnötig. Die Registrierungsschlüssel sind für die Ausführung des Servers nicht erforderlich und werden, wenn Sie MySQL aus dem Noinstall-Archiv installieren, auch nicht erstellt.

Änderungen im Startmenü

Der MySQL-Installations-Assistent erstellt im Windows-Menü Start einen neuen Eintrag in einem MySQL-Menü, welches nach der installierten MySQL-Hauptversion benannt ist. Installieren Sie beispielsweise MySQL 5.1, dann erstellt der Installations-Assistent einen Abschnitt namens MySQL Server 5.1 im Menü Start.

In diesem neuen Abschnitt im Menü Start werden die folgenden Einträge eingerichtet:

Änderungen am Dateisystem

Der MySQL-Installations-Assistent installiert den MySQL 5.1 Server standardmäßig im Verzeichnis C:\Programme\MySQL\MySQL Server 5.1. Hierbei ist Programme das Standardverzeichnis für Anwendungen auf Ihrem System und 5.1 die Hauptversion Ihres MySQL Servers. Dies ist das empfohlene Verzeichnis für den MySQL Server. Es ersetzt die vormalige Standardposition C:\mysql.

Standardmäßig werden alle MySQL-Anwendungen in einem gemeinsamen Verzeichnis in C:\Programme\MySQL gespeichert. Hierbei ist Programme in Ihrer Windows-Installation das Standardverzeichnis für Anwendungen. Bei einer typischen MySQL-Installation auf einem Entwicklersystem könnte dies wie folgt aussehen:

C:\Programme\MySQL\MySQL Server 5.1
C:\Programme\MySQL\MySQL Administrator 1.0
C:\Programme\MySQL\MySQL Query Browser 1.0

Dieser Ansatz erleichtert Verwaltung und Pflege aller auf einem System installierten MySQL-Anwendungen.

Der MySQL-Installations-Assistent kann Server-Upgrades automatisch mithilfe der MSI-Aktualisierungsfunktionen durchführen. Das bedeutet, dass Sie eine vorhandene Installation nicht mehr manuell entfernen müssen, bevor Sie einen neuen Release installieren. Das Installationsprogramm beendet und entfernt den vorhandenen MySQL-Dienst selbsttätig, bevor die neue Version installiert wird.

Automatische Upgrades sind nur dann verfügbar, wenn Sie Aktualisierungen zwischen Installationen durchführen, die die gleiche Haupt- und Unterversionsnummern aufweisen. So kann etwa ein automatisches Upgrade von MySQL 4.1.5 auf MySQL 4.1.6 erfolgen, nicht jedoch von MySQL 5.0 auf MySQL 5.1.

Siehe auch Abschnitt 2.3.15, „Upgrade von MySQL unter Windows“.

Der MySQL-Konfigurations-Assistent hilft Ihnen bei der Automatisierung der Serverkonfiguration unter Windows. Der Konfigurations-Assistent erstellt eine benutzerdefinierte Datei my.ini. Hierzu stellt er Ihnen eine Reihe von Fragen und verknüpft Ihre Antworten dann mit einer Vorlage, um eine Datei my.ini zu erzeugen, die für Ihre Installation maßgeschneidert ist.

Der MySQL-Konfigurations-Assistent ist Bestandteil des MySQL 5.1-Servers und derzeit nur für Windows-Benutzer verfügbar.

Der MySQL-Konfigurations-Assistent ist zu einem Großteil Ergebnis des Feedbacks, das MySQL AB über viele Jahre hinweg von Benutzern erhalten hat. Sollten Sie feststellen, dass eine für Sie wesentliche Funktionalität fehlt, dann melden Sie dies bitte in unserer Bugdatenbank. Hinweise zur Vorgehensweise finden Sie in Abschnitt 1.8, „Wie man Bugs oder Probleme meldet“.

Der MySQL-Konfigurations-Assistent wird normalerweise über den MySQL-Installations-Assistenten gestartet, wenn dieser beendet wird. Sie können den Konfigurations-Assistenten aber auch durch Auswahl des Eintrags MySQL Server Instance Config Wizard im Abschnitt MySQL des Windows-Menüs Start aufrufen.

Alternativ navigieren Sie zum Verzeichnis bin Ihrer MySQL-Installation und rufen die Datei MySQLInstanceConfig.exe direkt auf.

Wenn der MySQL-Konfigurations-Assistent eine vorhandene Datei my.ini erkennt, können Sie wahlweise den vorhandenen Server umkonfigurieren oder die Serverinstanz durch Löschen von my.ini entfernen und den MySQL-Dienst beenden und entfernen.

Wenn Sie den vorhandenen Server umkonfigurieren wollen, wählen Sie die Option Re-configure Instance und klicken dann auf die Schaltfläche Next. Ihre vorhandene Datei my.ini wird nun in mytimestamp.ini.bak umbenannt, wobei timestamp ein Zeitstempel mit dem Datum und der Uhrzeit des Zeitpunkts ist, an dem die vorhandene my.ini erstellt worden ist. Wenn Sie die vorhandene Serverinstanz entfernen wollen, wählen Sie die Option Remove Instance und klicken dann auf die Schaltfläche Next.

Wählen Sie die Option Remove Instance, dann wird ein Bestätigungsfenster aufgerufen. Klicken Sie auf die Schaltfläche Execute. Der MySQL-Konfigurations-Assistent beendet und entfernt nun den MySQL-Dienst. Nachfolgend löscht er die Datei my.ini. Die Serverinstallation und ihr Ordner data werden nicht entfernt.

Wenn Sie die Option Re-configure Instance auswählen, wird das Dialogfeld Configuration Type angezeigt. Hier können Sie den Installationstyp auswählen, den Sie konfigurieren wollen.

Wenn Sie den MySQL-Konfigurations-Assistenten für eine neue MySQL-Installation aufrufen oder die Option Re-configure Instance für eine vorhandene Installation auswählen, wird das Dialogfeld Configuration Type aufgerufen.

Es stehen zwei Konfigurationsmethoden zur Verfügung: Detailed Configuration und Standard Configuration. Die Option Standard Configuration ist für Neubenutzer vorgesehen, die direkt mit MySQL arbeiten wollen, ohne sich vorher Gedanken zur Serverkonfiguration machen zu müssen. Die Option Detailed Configuration ist hingegen für fortgeschrittene Benutzer gedacht, die eine exaktere Kontrolle über die Serverkonfiguration wünschen.