Kapitel 1. Allgemeine Informationen über MySQL
Zurück |  | Weiter

## Kapitel 1. Allgemeine Informationen über MySQL

Die MySQL®-Software ist ein sehr schneller und robuster SQL-Datenbankserver (Structured Query Language, strukturierte Abfragesprache), der Multi-Threading und Mehrbenutzerbetrieb unterstützt. MySQL Server ist für unternehmenskritische Produktionssysteme mit hoher Beanspruchung ebenso vorgesehen wie für die Einbettung in Software, die flächendeckend eingesetzt wird. MySQL ist ein eingetragenes Warenzeichen von MySQL AB.

Die MySQL-Software ist dual lizenziert: Der Benutzer kann wählen, ob er die MySQL-Software als Open-Source-Produkt gemäß der GNU General Public License (http://www.fsf.org/licenses/) verwenden oder eine kommerzielle Standardlizenz bei MySQL AB erwerben will. Weitere Informationen zu unseren Lizenzierungsrichtlinien erhalten Sie unter http://www.mysql.com/company/legal/licensing/.

Die folgende Liste beschreibt einige wesentliche Abschnitte dieses Handbuchs:

- Eine Beschreibung des Funktionsumfangs des MySQL-Datenbankservers finden Sie unter Abschnitt 1.4.2, „Die wichtigsten Features von MySQL“.

- Informationen zur Installation finden Sie in Kapitel 2, Installation von MySQL.

- Tipps zur Portierung der MySQL-Datenbanksoftware auf andere Architekturen oder Betriebssysteme finden Sie in Anhang E, Anmerkungen zur Portierung auf andere Systeme.

- Informationen zur Aktualisierung von MySQL 5.0 auf MySQL 5.1 sind in Abschnitt 2.10.1, „Upgrade von MySQL 5.0“, beschrieben.

- Ein einführendes Tutorial zum MySQL-Datenbankserver finden Sie in Kapitel 3, Einführung in MySQL: ein MySQL-Tutorial.

- Informationen zu Benchmarks finden Sie im Benchmark-Verzeichnis `sql-bench` Ihrer MySQL-Distribution.

- Eine Übersicht über neue Funktionen und Fehlerbehebungen (Bugfixes) finden Sie in Anhang D, MySQL-Änderungsverlauf (Change History).

- Bekannte Fehler und Funktionsprobleme werden in Abschnitt A.8, „Bekannte Fehler und konzeptionelle Unzulänglichkeiten in MySQL“, beschrieben.

- Abschnitt 1.6, „MySQL-Roadmap“, enthält eine Übersicht über zukünftige Vorhaben.

- Eine Liste aller an diesem Projekt Mitwirkenden finden Sie in Anhang C, Danksagungen.

Wichtig:

Um Fehler (häufig auch als „Bugs“ bezeichnet) zu melden, besuchen Sie die Seite http://bugs.mysql.com. Siehe auch Abschnitt 1.8, „Wie man Bugs oder Probleme meldet“.

Wenn Sie einen kritischen Sicherheitsfehler in MySQL Server festgestellt haben, teilen Sie uns dies bitte umgehend via E-Mail an `<security@mysql.com>` mit.

## 1.1. Über dieses Handbuch

Dies ist das Referenzhandbuch zum MySQL-Datenbanksystem, Version 5.1 bis einschließlich Release 5.1.5-alpha. Aufgrund der zahlreichen funktionalen und auch sonstigen Unterschiede zwischen MySQL 5.1 und vorherigen Versionen ist dieses Handbuch nicht für die Verwendung mit älteren Versionen der MySQL-Software vorgesehen. Wenn Sie ein älteres Release der MySQL-Software verwenden, finden Sie weitere Informationen im MySQL 5.0 Reference Manual, wo die 5.0-Serie der MySQL-Releases behandelt wird, oder im MySQL-Referenzhandbuch für die Versionen 3.23, 4.0 und 4.1, wo die Serien 3.23, 4.0 und 4.1 der MySQL-Software beschrieben werden. Unterschiede zwischen den Unterversionen von MySQL 5.1 sind unter Angabe der Release-Nummern (5.1.`x`) im vorliegenden Text enthalten.

Da dieses Handbuch als Referenzhandbuch dient, finden Sie hier keine allgemeinen Hinweise zu SQL oder zu Konzepten relationaler Datenbanken. Ebenso wenig wird beschrieben, wie Sie Ihr Betriebssystem oder einen Befehlszeilen-Interpreter verwenden.

Die MySQL-Datenbanksoftware wird fortlaufend weiterentwickelt. Auch das Referenzhandbuch wird häufig aktualisiert. Die aktuelle Version des Handbuchs ist in durchsuchbarer Form online unter http://dev.mysql.com/doc/ verfügbar. Weitere Formate wie HTML, PDF oder CHM (Windows-Hilfeformat) sind ebenfalls erhältlich.

Die Quelldateien des Referenzhandbuchs sind im Format DocBook XML verfasst. Die HTML-Version und weitere Versionen werden automatisch erzeugt. Dabei kommen in erster Linie die DocBook XSL-Stylesheets zum Einsatz. Informationen zu DocBook finden Sie unter http://docbook.org/.

Haben Sie Anmerkungen zu Ergänzungen oder Fehlerkorrekturen in diesem Handbuch, dann senden Sie bitte eine E-Mail an das Dokumentationsteam (`<docs@mysql.com>`).

Dieses Handbuch wurde ursprünglich verfasst von David Axmark und Michael „Monty“ Widenius. Es wird vom MySQL-Dokumentationsteam gepflegt, zu dem Paul DuBois, Stefan Hinz, Mike Hillyer und Jon Stephens gehören. Die Namen zahlreicher weiterer Mitwirkender finden Sie unter Anhang C, Danksagungen.

Die Urheberrechte für dieses Handbuch liegen bei dem schwedischen Unternehmen MySQL AB. MySQL® und das MySQL-Logo sind eingetragene Warenzeichen von MySQL AB. Weitere in diesem Handbuch verwendete Warenzeichen und eingetragene Warenzeichen sind Eigentum der jeweiligen Besitzer und dienen lediglich erläuternden Zwecken.

## 1.2. Konventionen in diesem Handbuch

Dieses Handbuch verwendet folgende typografische Konventionen:

- `Text in diesem Stil` wird für SQL-Anweisungen sowie für Datenbank-, Tabellen- und Spaltennamen verwendet, darüber hinaus für Listings, Quellcode und Umgebungsvariablen. Beispiel: „Um die Berechtigungstabellen neu einzuladen, benutzen Sie die Anweisung `FLUSH PRIVILEGES`.“

- `Text in diesem Stil` bezeichnet Eingaben, die Sie in Beispielen eintippen.

- Text in diesem Stil bezeichnet die Namen ausführbarer Programme und Skripte, beispielsweise mysql (das MySQL-Befehlszeilen-Clientprogramm) und mysqld (die ausführbare MySQL Server-Datei).

- `Text in diesem Stil` wird für variable Eingaben verwendet, bei denen Sie einen Wert Ihrer Wahl eingeben.

- Datei- und Verzeichnisnamen werden wie folgt geschrieben: „Die globale Optionsdatei `my.cnf` befindet sich im Verzeichnis `/etc`.“

- Zeichenfolgen werden so geschrieben: „Um einen Platzhalter anzugeben, verwenden Sie das Zeichen ‘`%`’.“

- Text in diesem Stil wird für Hervorhebungen verwendet.

- Text in diesem Stil wird für Tabellenüberschriften und für besonders starke Hervorhebung verwendet.

Wenn Befehle dargestellt werden, die innerhalb eines bestimmten Programms eingegeben werden sollen, gibt die Eingabeaufforderung am Zeilenbeginn das zu verwendende Programm an. Beispielsweise gibt `shell>` einen Befehl an, der von einer Login-Shell ausgeführt werden soll. `mysql>` gibt eine Anweisung an, die innerhalb des Clientprogramms mysql ausgeführt wird.

    shell> geben Sie hier einen Shell-Befehl ein
    mysql> geben Sie hier eine MySQL-Anweisung ein

Die „Shell“ ist Ihr Befehlszeilen-Interpreter. Unter Unix ist das typischerweise ein Programm wie sh, csh oder bash. Unter Windows ist das entsprechende Programm command.com oder cmd.exe, die typischerweise in einem Eingabefenster ausgeführt werden.

Wenn Sie einen Befehl oder eine Anweisung aus einem Beispiel eingeben, geben Sie bitte nicht die Eingabeaufforderung (den Prompt) ein, die in dem Beispiel angegeben ist.

Innerhalb von Anweisungen müssen Datenbank-, Tabellen- und Spaltennamen oftmals ersetzt werden. Das Handbuch verwendet zum Kenntlichmachen, dass eine Ersetzung notwendig ist, `db_name`, `tbl_name` und `col_name`. Beispielsweise könnten Sie folgende Anweisung finden:

    mysql> SELECT col_name FROM db_name.tbl_name;

Das bedeutet, dass Sie bei Eingabe einer ähnlichen Anweisung Ihre eigenen Namen für Datenbank, Tabelle und Spalten angeben sollen, beispielsweise so:

    mysql> SELECT author_name FROM biblio_db.author_list;

SQL-Schlüsselwörter sind unabhängig von der verwendeten Groß- und Kleinschreibung. Dieses Handbuch verwendet ausschließlich zur besseren Kenntlichmachung Großschreibung.

In Syntaxbeschreibungen geben eckige Klammern (‘`[`’ und ‘`]`’) optionale Wörter oder Klauseln an. In folgender Anweisung beispielsweise ist `IF EXISTS` optional:

    DROP TABLE [IF EXISTS] tbl_name

Wenn ein Syntaxelement eine Anzahl von Alternativen hat, werden diese durch vertikale Striche (‘`|`’) getrennt. Wenn ein Element ausgewählt werden kann, aber nicht muss, werden die Alternativen in eckigen Klammern (‘`[`’ und ‘`]`’) angegeben:

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

Wenn ein Element ausgewählt werden muss, werden die Alternativen in geschweiften Klammern (‘`{`’ und ‘`}`’) angegeben:

    {DESCRIBE | DESC} tbl_name [col_name | wild]

Eine Auslassung (`…`) gibt an, dass ein Abschnitt einer Anweisung weggelassen wurde, normalerweise, um eine kürzere Version einer komplexeren Syntax darzustellen. Beispielsweise ist `INSERT … SELECT` die Abkürzung der Form der `INSERT`-Anweisung, bei der eine `SELECT`-Anweisung folgt.

Eine Auslassung kann darüber hinaus angeben, dass das vorhergehende Syntaxelement einer Anweisung wiederholt werden kann. Im folgenden Beispiel können mehrere `reset_option`-Werte angegeben werden, wobei jedem Wert nach dem ersten ein Komma vorangestellt wird:

    RESET reset_option [,reset_option] ...

Befehle zum Setzen von Shell-Variablen werden in der Syntax der Bourne-Shell dargestellt, wie beispielsweise die Folge zum Setzen der Umgebungsvariablen `CC` und der Ausführung des Befehls configure:

    shell> CC=gcc ./configure

Wenn Sie csh oder tcsh verwenden, müssen Sie die Befehle etwas anders eingeben:

    shell> setenv CC gcc
    shell> ./configure

## 1.3. Was ist MySQL AB?

MySQL AB ist das Unternehmen der Gründer und Hauptentwickler von MySQL. MySQL AB wurde ursprünglich in Schweden von David Axmark, Allan Larsson und Michael „Monty“ Widenius gegründet.

Wir entwickeln die MySQL-Datenbanksoftware mit viel Engagement und machen sie unseren Benutzern bekannt. MySQL AB gehört das Copyright am MySQL-Quellcode, das MySQL-Logo und (eingetragene) Warenzeichen und dieses Handbuch. Siehe auch Abschnitt 1.4, „Was ist MySQL?“.

Die Kernwerte von MySQL zeugen von unserem Engagement für MySQL und Open Source.

Diese Kernwerte bestimmen, wie MySQL AB mit der MySQL Server-Software verfährt:

- Sie soll die beste und meistgenutzte Datenbank der Welt sein,

- allen verfügbar und für alle erschwinglich,

- leicht zu benutzen,

- ständig in Verbesserung begriffen, jedoch stets schnell und sicher,

- frei von Bugs und

- es soll Spaß machen, sie zu benutzen.

Die Kernwerte des Unternehmens MySQL AB und seiner Angestellten sind:

- Wir sind der Open-Source-Philosophie verpflichtet und unterstützen die Open-Source-Gemeinschaft,

- versuchen, stets gute Bürger zu sein,

- arbeiten vorzugsweise mit Partnern zusammen, die unsere Werte und Geisteshaltung teilen,

- beantworten E-Mails und stellen Support zur Verfügung,

- sind ein virtuelles Unternehmen, das mit anderen Netzwerkverbunde bildet, und

- arbeiten gegen Softwarepatente.

Die MySQL-Website (http://www.mysql.com/) enthält stets die neuesten Informationen über MySQL und MySQL AB.

Nebenbei bemerkt ist das „AB“ im Firmennamen die Abkürzung für das schwedische Wort „aktiebolag“, was „Aktiengesellschaft“ bedeutet. In anderen Ländern verwenden wir stattdessen „MySQL, Inc.“ oder „MySQL GmbH“ (für regionale Niederlassungen). Diese befinden sich in den USA beziehungsweise in Deutschland.

## 1.4. Was ist MySQL?

MySQL, das populärste quelloffene SQL-Datenbankmanagementsystem der Welt, wird von MySQL AB entwickelt, vertrieben und supportet. MySQL AB ist ein kommerzielles, von den MySQL-Entwicklern gegründetes Unternehmen. Es ist ein Open-Source-Unternehmen der zweiten Generation, das die Werte und Methodik von Open Source mit einem erfolgreichen Geschäftsmodell verbindet.

Die MySQL-Website (http://www.mysql.com/) enthält die neuesten Informationen über MySQL-Software und MySQL AB.

- MySQL ist ein Datenbankmanagementsystem.

  Eine Datenbank ist eine strukturierte Sammlung von Daten. Das kann alles von einer einfachen Einkaufsliste über eine Bildergalerie bis zu riesigen Informationsmengen in einem Firmennetzwerk sein. Um Daten in einer Computerdatenbank hinzuzufügen, auf sie zuzugreifen oder um sie zu verarbeiten, wird ein Datenbankmanagementsystem wie der MySQL Server benötigt. Weil Computer in der Handhabung großer Datenmengen sehr gut sind, spielen Datenbankmanagementsysteme eine zentrale Rolle beim Einsatz von Computern, sowohl als selbstständige Hilfsprogramme als auch als Teile anderer Anwendungen.

- MySQL ist ein relationales Datenbankmanagementsystem.

  Eine relationale Datenbank speichert Daten in separaten Tabellen, statt alle Daten in einem einzigen großen Speicherraum abzulegen. Das sorgt für Vorteile hinsichtlich Geschwindigkeit und Flexibilität. Das „SQL“ in „MySQL“ steht für „Structured Query Language“ (strukturierte Abfragesprache). SQL ist die gebräuchlichste standardisierte Sprache, die für den Zugriff auf Datenbanken eingesetzt wird. Sie ist im ANSI/ISO-SQL-Standard festgelegt. Dieser, kurz SQL-Standard genannt, hat sich seit 1986 entwickelt. Es existieren verschiedene Versionen. In diesem Handbuch bezieht sich „SQL-92“ auf den im Jahre 1992 veröffentlichten Standard, „SQL:1999“ auf den 1999 veröffentlichten und „SQL:2003“ auf die aktuelle Version des Standards. Wir benutzen die Bezeichnung „der SQL-Standard“ für die aktuelle Version des SQL-Standards.

- MySQL-Software ist quelloffene (Open Source) Software.

  Open Source bedeutet, dass es für jeden möglich ist, die Software zu benutzen und zu verändern. Jeder kann sie vom Internet herunterladen und ohne Bezahlung verwenden. Wenn man will, kann man sich den Quellcode ansehen und diesen nach den eigenen Wünschen abwandeln. MySQL verwendet die Lizenz GPL (GNU General Public License), http://www.fsf.org/licenses/. Diese legt fest, was man in unterschiedlichen Fällen mit der Software machen darf und was nicht. Wenn Ihnen ein Gebrauch unter der GPL nicht zusagt oder Sie MySQL in eine kommerzielle Applikation einbetten wollen, können Sie von uns eine kommerzielle Version erwerben. Weitere Informationen zur Lizenz finden Sie auf unserer Website (http://www.mysql.com/company/legal/licensing/).

- Der MySQL-Datenbankserver ist sehr schnell, zuverlässig und einfach zu benutzen.

  Wenn es das ist, wonach Sie suchen, sollten Sie MySQL ausprobieren. MySQL Server hat darüber hinaus viele praktische Features, die in enger Zusammenarbeit mit unseren Benutzern entwickelt wurden. Einen Leistungsvergleich zwischen MySQL Server und anderen Datenbanksystemen finden Sie auf unserer Benchmark-Seite unter Abschnitt 7.1.4, „Die MySQL-Benchmark-Reihe“.

  MySQL Server wurde ursprünglich für den Zweck entwickelt, große Datenbanken sehr viel schneller als bestehende Lösungen zu handhaben. Er ist seit Jahren in äußerst anspruchsvollen Produktionsumgebungen im Einsatz. Obwohl er ständig weiterentwickelt wird, bietet MySQL Server schon heute ein reiches Set von Funktionen. Flexible Anbindungsmöglichkeiten, Geschwindigkeit und Sicherheit machen MySQL Server äußerst geeignet für den Zugriff auf Datenbanken im Internet.

- MySQL Server arbeitet als Client-Server-Version und in eingebetteten Systemen.

  Die MySQL-Datenbanksoftware ist ein Client-Server-System, das aus einem Mehr-Thread-SQL-Server besteht, der verschiedene Backends sowie diverse Clientprogramme und -bibliotheken und Verwaltungswerkzeuge unterstützt und mittels vieler verschiedener Programmierschnittstellen (API) angesprochen werden kann.

  MySQL Server ist auch als eingebettete Mehr-Thread-Bibliothek verfügbar, die Sie in Ihre Applikationen einlinken können, um ein schnelles, kleines und leicht zu verwaltendes Einzelprodukt zu erhalten.

- Es gibt eine große Zahl von Dritten beigesteuerter Software.

  Es ist recht wahrscheinlich, dass Ihre Lieblingsapplikation oder -sprache bereits den MySQL-Datenbankserver unterstützt.

Die offizielle Aussprache von „MySQL“ ist „Mai Es Ku Ell“ (nicht „Mai Sie Quell“).

### 1.4.1. Geschichte von MySQL

Unsere Absicht war ursprünglich, 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 zu der Ü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 Basisverzeichnis 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 die Tochter von Monty Widenius, einem der Gründer von MySQL, heißt My. Welcher der beiden Umstände MySQL den Namen gab, ist immer noch ein Rätsel, sogar für uns.

Der Name des MySQL-Delphins (unseres Logos) ist „Sakila“. Er wurde von den Gründern von MySQL AB aus einer riesigen Liste mit Vorschlägen unserer Benutzer im Rahmen des „Name the Dolphin“-Wettbewerbs gewählt. Der Name wurde von Ambrose Twebaze, einem Open-Source-Software-Entwickler aus Swasiland, Afrika, eingereicht. Nach Ambrose hat der weibliche Vorname Sakila seine Wurzeln in Siswati, der Sprache von Swasiland. Sakila ist darüber hinaus der Name einer Stadt in Arusha, Tansania, die in der Nähe von Ambroses Herkunftsland, Uganda, liegt.

### 1.4.2. Die wichtigsten Features von MySQL

Die folgende Liste beschreibt einige wichtige Charakteristika von MySQL. Weitere Informationen sind unter Abschnitt 1.6, „MySQL-Roadmap“, zu finden.

Interna und Portabilität:

- Geschrieben in C und C++.

- Getestet mit einer großen Anzahl unterschiedlicher Compiler.

- Läuft auf vielen Plattformen, siehe Abschnitt 2.1.1, „Betriebssysteme, die von MySQL unterstützt werden“.

- Benutzt aus Gründen der Portabilität GNU Automake, Autoconf und Libtool.

- APIs für C, C++, Eiffel, Java, Perl, PHP, Python, Ruby und Tcl stehen zur Verfügung, siehe Kapitel 24, APIs und Bibliotheken.

- Voll multithread-fähig unter Benutzung von Kernel-Threads. Das bedeutet, dass Sie sehr einfach mehrere Prozessoren benutzen können, falls verfügbar.

- Enthält transaktionale und nichttransaktionale Speicher-Engines.

- Verwendet sehr schnelle B-Baum-Festplatten-Tabellen (`MyISAM`) mit Indexkompression.

- Es ist verhältnismäßig einfach, neue Speicher-Engines hinzuzufügen. Das ist praktisch, wenn man beispielsweise einer Inhouse-Datenbank eine SQL-Schnittstelle hinzufügen möchte.

- Ein sehr schnelles thread-basiertes Speicherzuordnungssystem.

- Sehr schnelle Joins durch Benutzung eines optimierten Multi-Joins in einem Durchgang.

- Im Arbeitsspeicher gehaltene Hash-Tabellen, die als temporäre Tabellen benutzt werden.

- SQL-Funktionen sind durch eine hochoptimierte Klassenbibliothek implementiert und sollten so schnell sein, wie es überhaupt geht. Üblicherweise gibt es keinerlei Speicherzuordnung nach der Initialisierung von Anfragen.

- Keine Speicherlecks (memory leaks). MySQL wird mit Purify getestet, einem kommerziellen Werkzeug zur Entdeckung von Speicherlecks, und mit Valgrind, einem GPL-Werkzeug (http://developer.kde.org/~sewardj/).

- Der Server ist als separates Programm verfügbar, das in einer vernetzten Client-Server-Umgebung arbeitet. Es ist auch als Bibliothek erhältlich, die in Einzelanwendungen eingebettet werden kann. Solche Applikationen können isoliert oder in Umgebungen eingesetzt werden, in denen kein Netzwerk zur Verfügung steht.

Datentypen:

- Viele Datentypen: vorzeichenbehaftete und vorzeichenlose Integers, die 1, 2, 3, 4 und 8 Byte lang sein können, `FLOAT`, `DOUBLE`, `CHAR`, `VARCHAR`, `TEXT`, `BLOB`, `DATE`, `TIME`, `DATETIME`, `TIMESTAMP`, `YEAR`, `SET`, `ENUM` und OpenGIS-Typen (raumbezogene Daten). Siehe Kapitel 11, Datentypen.

- Datensätze fester und variabler Länge.

Anweisungen und Funktionen:

- Volle Operator- und Funktionsunterstützung in `SELECT`- und `WHERE`-Klauseln von Abfragen. Beispiel:

      mysql> SELECT CONCAT(first_name, ' ', last_name)
          -> FROM citizen
          -> WHERE income/dependents > 10000 AND age > 30;

- Volle Unterstützung der SQL-Klauseln `GROUP BY` und `ORDER BY`. Unterstützung von Gruppierungsfunktionen (`COUNT()`, `COUNT(DISTINCT ...)`, `AVG()`, `STD()`, `SUM()`, `MAX()`, `MIN()` und `GROUP_CONCAT()`).

- Unterstützung von `LEFT OUTER JOIN` und `RIGHT OUTER JOIN` sowohl mit Standard-SQL- als auch mit ODBC-Syntax.

- Unterstützung für Aliase auf Tabellen und Spalten, wie im SQL-Standard verlangt.

- `DELETE`, `INSERT`, `REPLACE` und `UPDATE` geben die Anzahl der geänderten (betroffenen) Zeilen zurück. Durch Setzen eines Flags beim Verbinden mit dem Server lässt sich stattdessen die Anzahl der übereinstimmenden Zeilen zurückgeben.

- Die MySQL-spezifische Anweisung `SHOW` kann zum Abruf von Informationen über Datenbanken, Speicher-Engines, Tabellen und Indizes verwendet werden.

  Mit der Anweisung `EXPLAIN` lässt sich feststellen, wie der Optimierer eine Abfrage auflöst.

- Funktionsnamen vertragen sich mit Tabellen- und Spaltennamen. Beispielsweise ist `ABS` ein gültiger Spaltenname. Als einzige Einschränkung dürfen bei einem Funktionsaufruf dem Funktionsnamen keine Leerzeichen folgen, siehe Abschnitt 9.5, „Ist MySQL pingelig hinsichtlich reservierter Wörter?“.

- Ab MySQL 3.22 können Tabellen in unterschiedlichen Datenbanken in einer Abfrage verwendet werden.

Sicherheit:

- MySQL besitzt ein sehr flexibles und sicheres Berechtigungs- und Kennwortsystem, das Host-basierte Überprüfung unterstützt. Kennwörter sind sicher, weil jegliche Übermittlung beim Verbinden mit dem Server verschlüsselt erfolgt.

Skalierbarkeit und Grenzen:

- Handhabt große Datenbanken. Wir selbst benutzen Datenbanken mit mehr als 50 Millionen Datensätzen und kennen Benutzer, die MySQL Server mit 60.000 Tabellen und über 5 Milliarden Zeilen benutzen.

- Pro Tabelle sind bis zu 64 Indizes erlaubt (32 vor MySQL 4.1.2). Jeder Index kann aus 1 bis 16 Spalten oder Spaltenteilen bestehen. Die größte Indexweite beträgt 1.000 Byte (500 vor MySQL 4.1.2). Indizes können Präfixe einer Spalte bei folgenden Spaltentypen verwenden: `CHAR`, `VARCHAR`, `BLOB` und `TEXT`.

Konnektivität:

- Clients können sich mit dem MySQL Server über TCP/IP-Sockets verbinden. Das ist auf jeder Plattform möglich. Auf Windows-Systemen der NT-Serie (NT, 2000, XP, 2003, Vista) können sich Clients mittels Named Pipes verbinden. Auf Unix-ähnlichen Systemen können Clients Unix-Domain-Socketdateien verwenden.

- Ab MySQL 4.1 werden unter Windows auch Shared-Memory-Verbindungen unterstützt, wenn der Server mit der Option `--shared-memory` gestartet wurde. Clients können sich über Shared Memory mit der Option `--protocol=memory` verbinden.

- Die Schnittstelle Connector/ODBC (MyODBC) stellt MySQL-Unterstützung für Clientprogramme zur Verfügung, die ODBC (Open Database Connectivity) benutzen. Beispielsweise können sie damit von MS Access auf MySQL Server zugreifen. Clients können unter Windows und Unix laufen. Der Quellcode von MyODBC ist offen. Alle Funktionen von ODBC 2.5 werden unterstützt sowie darüber hinaus viele weitere, siehe Kapitel 25, Connectors.

- Die Schnittstelle Connector/J stellt MySQL-Unterstützung für Java-Clientprogramme zur Verfügung, die JDBC-Verbindungen benutzen. Clients können unter Windows und Unix laufen. Der Quellcode von Connector/J ist offen. Siehe Kapitel 25, Connectors.

- Mit MySQL Connector/NET können Entwickler auf einfache Art .NET-Applikationen entwickeln, die sichere, hochperformante Datenverbindungen mit MySQL benötigen. Es enthält die erforderlichen ADO.NET-Schnittstellen und lässt sich in Werkzeuge einbinden, die ADO.NET-kompatibel sind. Entwickler können Applikationen mit der .NET-Sprache ihrer Wahl herstellen. MySQL Connector/NET ist ein voll verwalteter ADO.NET-Treiber, der zu 100 % in C# geschrieben wurde, siehe Kapitel 25, Connectors.

Lokalisierung:

- Der Server kann Clients Fehlermeldungen in vielen Sprachen ausgeben, siehe Abschnitt 5.11.2, „Nicht englische Fehlermeldungen“.

- Volle Unterstützung für diverse Zeichensätze, beispielsweise `latin1` (cp1252), `german`, `big5`, `ujis`. In Tabellen- und Spaltennamen sind beispielsweise die Zeichen ‘`å`’, ‘`ä`’ und ‘`ö`’ zulässig. Ab MySQL 4.1 wird Unicode unterstützt.

- Alle Daten werden mit dem ausgewählten Zeichensatz gespeichert. Alle Vergleiche für normale String-Spalten unterscheiden nicht nach Groß- und Kleinschreibung.

- Sortierungen werden mit dem ausgewählten Zeichensatz durchgeführt, wobei die schwedische Sortierfolge als Vorgabe ausgewählt ist. Das lässt sich beim Start des MySQL Servers ändern. Schauen Sie sich als Beispiel einer fortgeschrittenen Sortierfolge den tschechischen Sortiercode an. MySQL Server unterstützt viele verschiedene Zeichensätze, die beim Kompilieren von MySQL sowie zur Laufzeit angegeben werden können.

Clients und Werkzeuge:

- MySQL Server hat eingebaute SQL-Anweisungen zum Prüfen, Optimieren und Reparieren von Tabellen. Diese Anweisungen sind auch von der Befehlszeile aus zugänglich, über das Clientprogramm mysqlcheck. Darüber hinaus enthält MySQL myisamchk, ein sehr schnelles Hilfsprogramm zum Durchführen dieser Operationen auf `MyISAM`-Tabellen, siehe Kapitel 5, Datenbankverwaltung.

- Alle MySQL-Programme können mit den Optionen `--help` und `-?` aufgerufen werden, die direkte Hilfestellungen anzeigen.

### 1.4.3. Wie stabil ist MySQL?

Dieser Abschnitt beschäftigt sich mit den Fragen „Wie stabil ist MySQL?“ und „Kann ich mich auf MySQL bei diesem Projekt verlassen?“. Wir werden versuchen, einige Dinge klarzustellen und einige der wichtigeren Fragen zu beantworten, die offensichtlich viele Leute beschäftigen. Dieser Abschnitt wurde aus Informationen zusammengestellt, die aus den Mailinglisten gesammelt wurden, die sehr aktiv beim Berichten von Problemen und Nutzungsbeispielen sind.

Der ursprüngliche Code stammt aus den frühen 1980er Jahren. Er stellt eine stabile Codebasis zur Verfügung, und das Tabllenformat `ISAM`, das von der ursprünglichen Speicher-Engine verwendet wurde, ist immer noch abwärtskompatibel. 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 außerhalb 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 und auf das Design zurückzuführen sind. Siehe Abschnitt A.8, „Bekannte Fehler und konzeptionelle Unzulänglichkeiten in MySQL“.

MySQL ist in mehreren Ebenen mit unabhängigen Modulen geschrieben. Diese Module sind im Folgenden aufgeführt, wobei angezeigt wird, wie gut getestet jedes von ihnen ist:

- Replikation (stabil)

  Große Gruppen von Servern, die Replikation verwenden, sind im Produktionseinsatz, mit guten Ergebnissen. Die Entwicklung erweiterter Replikationsfeatures wird fortgesetzt.

- `InnoDB`-Tabellen (stabil)

  Die transaktionale Speicher-Engine `InnoDB` ist seit Version 3.23.49 stabil. `InnoDB` wird in großen Hochlast-Produktionssystemen eingesetzt.

- Volltextsuche (stabil)

  Die Volltextsuche wird viel verwendet. Wichtige Detailverbesserungen wurden in MySQL 4.0 und 4.1 hinzugefügt.

- `MyODBC` 3.51 (stabil)

  `MyODBC` 3.51 verwendet ODBC SDK 3.51 und ist im breiten Produktionseinsatz. Einige Probleme scheinen applikationsbedingt zu sein und unabhängig vom ODBC-Treiber oder den zugrunde liegenden Datenbanken.

### 1.4.4. Wie groß können MySQL-Tabellen sein?

MySQL Version 3.22 hatte eine Begrenzung auf 4 Gbyte bei der Tabellengröße. Mit der Speicher-Engine `MyISAM` in MySQL Version 3.23 wurde die maximale Tabellengröße auf 65.536 Terabyte (2567 – 1 Byte) erhöht. Das bedeutet, dass die maximale effektive Tabellengröße von MySQL-Datenbanken normalerweise durch Beschränkungen des Betriebssystems hinsichtlich Dateigrößen festgelegt ist, nicht durch MySQL-interne Grenzen.

Die Speicher-Engine `InnoDB` hält `InnoDB`-Tabellen in einem Tablespace, der aus mehreren Dateien bestehen kann. Hierdurch ist es möglich, dass eine Tabelle die maximale Größe einer einzelnen Datei überschreitet. Der Tablespace kann auch rohe Festplattenpartitionen beinhalten, wodurch extrem große Tabellen möglich werden. Die maximale Größe des Tablespaces beträgt 64 Terabyte.

Im Folgenden sind einige Beispiele für Dateigrößen aufgeführt, die durch Betriebssysteme veranlasst sind. Die Tabelle soll nur als Anhaltspunkt dienen. Sie ist in keiner Weise auf Vollständigkeit bedacht. Die aktuellsten Informationen erhalten Sie in der Dokumentation Ihres Betriebssystems.

Betriebssystem | Maximale Dateigröße
Linux 2.2-Intel 32-bit | 2 Gbyte (LFS: 4 Gbyte)
Linux 2.4+ | (mit Dateisystem ext3) 4 Tbyte
Solaris 9/10 | 16 Tbyte
NetWare w/NSS Dateisystem | 8 Tbyte
Win32 w/ FAT/FAT32 | 2 Gbyte/4 Gbyte
Win32 w/ NTFS | 2 Tbyte (möglicherweise mehr)
Mac OS X w/ HFS+ | 2 Tbyte

Unter Linux 2.2 können Sie `MyISAM`-Tabellen mit mehr als 2 Gbyte erzeugen, indem Sie den Large File Support(LFS)-Patch für das Dateisystem ext2 einspielen. Unter Linux 2.4 bestehen Patches für ReiserFS, die Unterstützung für große Dateien bieten (bis zu 2 Tbyte). Die meisten aktuellen Linux-Distributionen basieren auf Kernel 2.4 oder höher und enthalten sämtliche erforderlichen LFS-Patches. Mit JFS und XFS sind unter Linux Dateien im Petabytebereich und darüber hinaus möglich. Die maximal erreichbare Dateigröße hängt jedoch immer noch von mehreren Faktoren ab, unter anderem vom Dateisystem, auf dem MySQL-Tabellen gespeichert werden.

Einen detaillierten Überblick über LFS unter Linux bietet die Seite Large File Support in Linux von Andreas Jäger, die Sie hier finden: http://www.suse.de/~aj/linux_lfs.html.

Wichtiger Hinweis für Windows-Benutzer: FAT und VFAT (FAT32) sind nicht für den Produktionseinsatz von MySQL geeignet. Benutzen Sie stattdessen NTFS.

Standardmäßig erzeugt MySQL `MyISAM`-Tabellen mit einer internen Struktur, die eine maximale Größe von 4 Gbyte erlaubt. Sie können die maximale Tabellengröße einer `MyISAM`-Tabelle mit der Anweisung `SHOW TABLE STATUS` oder mittels myisamchk -dv `tbl_name` feststellen. Siehe Abschnitt 13.5.4, „`SHOW`“.

Wenn Sie eine `MyISAM`-Tabelle brauchen, die größer als 4 Gbyte ist, und Ihr Betriebssystem große Dateien unterstützt, können Sie in der `CREATE TABLE`-Anweisung die Optionen `AVG_ROW_LENGTH` und `MAX_ROWS` verwenden, siehe Abschnitt 13.1.5, „`CREATE TABLE`“. Sie können diese Optionen auch mit `ALTER TABLE` ändern, um die maximale Tabellengröße zu verändern, nachdem die Tabelle erzeugt wurde, siehe Abschnitt 13.1.2, „`ALTER TABLE`“.

Darüber hinaus gibt es weitere Möglichkeiten, die Dateigrößenbeschränkung von `MyISAM`-Tabellen zu umgehen:

- Für schreibgeschützte Tabellen kann man myisampack verwenden, das diese komprimiert. myisampack komprimiert eine Tabelle normalerweise um mindestens 50 %, wodurch Sie im Endeffekt wesentlich größere Tabellen verwalten können. myisampack kann darüber hinaus mehrere Tabellen in einer einzigen Tabelle zusammenfassen, siehe Abschnitt 8.4, „myisampack — Erzeugung komprimierter, schreibgeschützter MyISAM Tabellen“.

- MySQL enthält eine `MERGE`-Bibliothek, die es erlaubt, eine Sammlung von `MyISAM`-Tabellen mit identischer Struktur als einzelne `MERGE`-Tabelle anzusprechen, siehe Abschnitt 14.3, „Die `MERGE`-Speicher-Engine“.

### 1.4.5. Jahr-2000-Konformität

Der MySQL Server selbst hat keine Probleme mit der Jahr-2000-Konformität:

- MySQL benutzt Unix-Zeitfunktionen und hat keine Probleme mit Datumsangaben bis `2069`. Alle zweistelligen Jahresangaben werden als Angaben zwischen `1970` und `2069`, betrachtet, was bedeutet, dass, wenn Sie `01` in einer Spalte speichern, MySQL dies als `2001` behandelt.

- Alle MySQL-Datumsfunktionen sind in einer Datei `sql/time.cc` gespeichert und sehr sorgfältig kodiert, um Jahr-2000-sicher zu sein.

- AB MySQL Version 3.22 kann der Spaltentyp `YEAR` das Jahr `0` und den Bereich von `1901` bis `2155` in einem Byte speichern und sie mit 2 oder 4 Ziffern anzeigen.

Das folgende einfache Beispiel demonstriert, dass MySQL Server keine Probleme mit `DATE`- oder `DATETIME`-Werten bis zum Jahr 9999 und keine Probleme mit `TIMESTAMP`-Werten bis ins Jahr 2030 hat:

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

    mysql> CREATE TABLE y2k (date DATE,
        ->                   date_time DATETIME,
        ->                   time_stamp TIMESTAMP);
    Query OK, 0 rows affected (0.01 sec)

    mysql> INSERT INTO y2k VALUES
        -> ('1998-12-31','1998-12-31 23:59:59','1998-12-31 23:59:59'),
        -> ('1999-01-01','1999-01-01 00:00:00','1999-01-01 00:00:00'),
        -> ('1999-09-09','1999-09-09 23:59:59','1999-09-09 23:59:59'),
        -> ('2000-01-01','2000-01-01 00:00:00','2000-01-01 00:00:00'),
        -> ('2000-02-28','2000-02-28 00:00:00','2000-02-28 00:00:00'),
        -> ('2000-02-29','2000-02-29 00:00:00','2000-02-29 00:00:00'),
        -> ('2000-03-01','2000-03-01 00:00:00','2000-03-01 00:00:00'),
        -> ('2000-12-31','2000-12-31 23:59:59','2000-12-31 23:59:59'),
        -> ('2001-01-01','2001-01-01 00:00:00','2001-01-01 00:00:00'),
        -> ('2004-12-31','2004-12-31 23:59:59','2004-12-31 23:59:59'),
        -> ('2005-01-01','2005-01-01 00:00:00','2005-01-01 00:00:00'),
        -> ('2030-01-01','2030-01-01 00:00:00','2030-01-01 00:00:00'),
        -> ('2040-01-01','2040-01-01 00:00:00','2040-01-01 00:00:00'),
        -> ('9999-12-31','9999-12-31 23:59:59','9999-12-31 23:59:59');
    Query OK, 14 rows affected, 2 warnings (0.00 sec)
    Records: 14  Duplicates: 0  Warnings: 2

    mysql> SELECT * FROM y2k;
    +------------+---------------------+---------------------+
    | date       | date_time           | time_stamp          |
    +------------+---------------------+---------------------+
    | 1998-12-31 | 1998-12-31 23:59:59 | 1998-12-31 23:59:59 |
    | 1999-01-01 | 1999-01-01 00:00:00 | 1999-01-01 00:00:00 |
    | 1999-09-09 | 1999-09-09 23:59:59 | 1999-09-09 23:59:59 |
    | 2000-01-01 | 2000-01-01 00:00:00 | 2000-01-01 00:00:00 |
    | 2000-02-28 | 2000-02-28 00:00:00 | 2000-02-28 00:00:00 |
    | 2000-02-29 | 2000-02-29 00:00:00 | 2000-02-29 00:00:00 |
    | 2000-03-01 | 2000-03-01 00:00:00 | 2000-03-01 00:00:00 |
    | 2000-12-31 | 2000-12-31 23:59:59 | 2000-12-31 23:59:59 |
    | 2001-01-01 | 2001-01-01 00:00:00 | 2001-01-01 00:00:00 |
    | 2004-12-31 | 2004-12-31 23:59:59 | 2004-12-31 23:59:59 |
    | 2005-01-01 | 2005-01-01 00:00:00 | 2005-01-01 00:00:00 |
    | 2030-01-01 | 2030-01-01 00:00:00 | 2030-01-01 00:00:00 |
    | 2040-01-01 | 2040-01-01 00:00:00 | 0000-00-00 00:00:00 |
    | 9999-12-31 | 9999-12-31 23:59:59 | 0000-00-00 00:00:00 |
    +------------+---------------------+---------------------+
    14 rows in set (0.00 sec)

Die letzten beiden `TIMESTAMP`-Spaltenwerte sind null, weil die Jahreswerte (`2040`, `9999`) das Maximum für `TIMESTAMP` überschreiten. Der Datentyp `TIMESTAMP`, der zur Speicherung der aktuellen Zeit verwendet wird, unterstützt Werte im Bereich zwischen `'1970-01-01 00:00:00'` und `'2030-01-01 00:00:00'` (auf 32-Bit-Maschinen; vorzeichenbehafteter Wert). Auf 64-Bit-Maschinen kann `TIMESTAMP` Werte bis zum Jahr `2106` (vorzeichenloser Wert) handhaben.

Obgleich MySQL Server selbst Jahr-2000-sicher ist, kann es Probleme mit Applikationen geben, die nicht Jahr-2000-konform sind. Beispielsweise speichern oder behandeln viele alte Applikationen Jahreswerte als zweistellige Zahlen (was uneindeutig ist). Dieses Problem wird durch Applikationen verschlimmert, die Werte wie `00` oder `99` als „fehlende“ Wertangaben betrachten. Solcherlei Probleme können schwer zu beheben sein.

Obwohl also MySQL Server keine Jahr-2000-Probleme aufweist, ist es die Aufgabe der Applikation, eindeutige Werte einzugeben. Siehe Abschnitt 11.3.4, „Jahr-2000-Probleme und Datumstypen“, hier sind die Regeln aufgeführt, die MySQL Server zur Handhabung uneindeutiger Datumseingaben mit zweistelligen Jahreswerten verwendet.

## 1.5. Überblick über das Datenbanksystem MaxDB

MaxDB ist eine Hochlast-Datenbank für den Unternehmenseinsatz. Das System ist SAP-zertifiziert.

MaxDB ist der neue Name des Datenbankverwaltungssystems, das vormals SAP DB hieß. Im Jahr 2003 schlossen sich SAP AG und MySQL AB zu einer Partnerschaft zusammen und gaben das Datenbanksystem unter dem neuen Markennamen MaxDB heraus. Die Entwicklung von MaxDB wurde seitdem wie gehabt durch das SAP-Entwicklungsteam fortgesetzt.

MySQL AB arbeitet eng mit dem MaxDB-Team bei SAP zusammen, um Verbesserungen in das Produkt MaxDB einzubringen. Beispielsweise werden zusammen neue native Treiber entwickelt, die eine effizientere Nutzung von MaxDB in der Open-Source-Community erlauben. Die Dokumentation wurde auf den MaxDB-Seiten verfügbar gemacht. Als gleichermaßen wichtig werden Features für das Zusammenspiel zwischen MySQL und MaxDB erachtet. Der neu entwickelte Synchronisationsmanager von MaxDB beispielsweise unterstützt die Synchronisation von Daten zwischen MaxDB und MySQL.

Das MaxDB-Datenbankverwaltungssystem hat eine andere Codebasis als das MySQL-Datenbankverwaltungssystem. MaxDB und MySQL sind voneinander unabhängige Produkte, die beide von MySQL AB angeboten werden.

MySQL AB bietet eine Vielzahl professioneller Dienstleistungen für MaxDB an.

### 1.5.1. Was ist MaxDB?

MaxDB ist ein zu ANSI SQL-92 (entry level) konformes relationales Datenbankverwaltungssystem (RDBMS) der SAP AG, das auch von MySQL AB vertrieben wird. MaxDB erfüllt alle Ansprüche an den Gebrauch im Unternehmen: Sicherheit, Skalierbarkeit, Nichtsequenzialität (Gleichzeitigkeit von Zugriffen) und Performanz. Es läuft auf allen größeren Betriebssystemen. Im Laufe der Jahre hat es unter Beweis gestellt, dass es in der Lage ist, SAP R/3 und Terabytes von Daten im Rund-um-die-Uhr-Betrieb zu unterstützen.

Die Datenbankentwicklung begann 1977 als Forschungsprojekt an der Technischen Universität Berlin. In den frühen 1980er Jahren wurde es zu einem Datenbankprodukt, das nacheinander Nixdort, Siemens Nixdorf, der Software AG und dann (bis heute) der SAP AG gehörte. Im Verlauf dieser Zeit wurde es VDN, Reflex, Supra 2, DDB/4, Entire SQL-DB-Server sowie ADABAS D genannt. 1997 übernahm SAP die Software von der Software AG und benannte sie in SAP DB um. Seit Oktober 2000 sind die SAP DB-Quellcodes unter der GNU General Public-Lizenz (siehe Anhang J, GNU General Public License) veröffentlicht.

Im Jahre 2003 gründeten die SAP AG und MySQL AB eine Partnerschaft und benannten das Datenbanksystem in MaxDB um.

### 1.5.2. Geschichte von MaxDB

Die Geschichte von MaxDB geht zurück auf SAP DB, das Datenbanksystem der SAP AG. MaxDB ist also die umbenannte und erweiterte Version von SAP DB. Seit vielen Jahren wird MaxDB in kleinen, mittleren und großen Installationen der mySAP-Business-Suite und anderen anspruchsvollen SQL-Anwendungen verwendet, die ein unternehmenstaugliches Datenbanksystem hinsichtlich Anzahl der Benutzer, transaktionaler Arbeitslast und Größe der Datenbank benötigen.

SAP DB war als Alternative zu Datenbanken von Drittanbietern wie Oracle oder Microsoft SQL Server sowie DB2 von IBM gedacht. Im Oktober 2000 veröffentlichte die SAP AG SAP DB unter der Lizenz GNU GPL (siehe Anhang J, GNU General Public License) und machte es damit zu quelloffener (Open Source) Software.

Heute kommt MaxDB in über 3500 SAP-Kundeninstallationen auf der ganzen Welt zum Einsatz. Darüber hinaus setzt die Mehrzahl aller Datenbankinstallationen unter Unix und Linux innerhalb der IT-Abteilung von SAP auf MaxDB auf. MaxDB ist optimiert auf Hochlast-Online-Transaction-Processing (OLTP) mit mehreren Tausend Benutzern und Datenbankgrößen zwischen mehreren hundert Gbytes und mehreren Tbytes.

Im Jahre 2003 begründeten SAP und MySQL eine Partnerschaft und eine Entwicklungskooperation. Im Rahmen dieser Zusammenarbeit wurde das System SAP DB der SAP AG unter dem Namen MaxDB by MySQL veröffentlicht. Das erste Release unter diesem Namen war 7.5 (November 2003).

Version 7.5 von MaxDB ist eine direkte Weiterentwicklung auf der Codebasis von SAP DB 7.4. Daher kann MaxDB 7.5 direkt als Upgrade von früheren SAP DB-Versionen ab 7.2.04 verwendet werden.

Das bestehende SAP-DB-Entwicklungsteam bei der SAP AG ist nach wie vor verantwortlich für die Entwicklung und den Support von MaxDB. MySQL AB und das MaxDB-Team bei SAP arbeiten an Verbesserungen am Produkt MaxDB eng zusammen; siehe Abschnitt 1.5, „Überblick über das Datenbanksystem MaxDB“. Sowohl die SAP AG als auch MySQL AB wickeln Verkauf und Auslieferung von MaxDB ab. Die Weiterentwicklung von MaxDB und MySQL Server setzt Synergien frei, die beiden Produktlinien zugute kommen.

MaxDB unterliegt dem kompletten Qualitätssicherungsprozess der SAP AB, bevor das Produkt mit SAP-Lösungen ausgeliefert oder zum Download auf der MySQL-Website zur Verfügung gestellt wird.

### 1.5.3. Features von MaxDB

MaxDB ist eine SAP-zertifizierte, quelloffene Hochlast-Datenbank für OLTP- und OLAP-Einsatzzwecke, die hohe Zuverlässigkeit und Verfügbarkeit sowie Skalierbarkeit und ein sehr umfangreiches Set von Features bietet. MaxDB ist auf große mySAP-Business-Suite-Umgebungen und sonstige Applikationen, die höchste Unternehmensfunktionalität benötigen, zugeschnitten und ergänzt somit den MySQL-Datenbankserver.

MaxDB arbeitet als Client-Server-Produkt. Es wurde hinsichtlich der Anforderungen von OLTP und Data Warehouse/OLAP/Entscheidungsunterstützung entwickelt und bietet folgende Vorteile:

- Einfache Konfiguration und Verwaltung: Ein grafischer Installationsmanager sowie ein Datenbankmanager als einziges Verwaltungswerkzeug für sämtliche DBMS-Operationen

- Rund-um-die-Uhr-Betrieb, keine geplanten Stillstandszeiten, keine ständige Beobachtung erforderlich: Automatische Verwaltung des Speicherplatzes ohne Notwendigkeit von Neuorganisationen

- Ausgefeilte Sicherungs- und Wiederherstellungsoptionen: Online-Backups und inkrementelle Sicherungen sowie Wiederherstellungsassistenten, die Sie durch das Recovery-Szenario führen

- Unterstützt eine große Zahl gleichzeitiger Benutzer, Datenbankgrößen im Terabytebereich und anspruchsvolle Arbeitslasten: Ausgereifte Zuverlässigkeit, Performanz und Skalierbarkeit

- Hochverfügbarkeit: Clusterunterstützung, Standby-Konfiguration, Hot-Standby-Konfiguration

### 1.5.4. Lizenzierung und Support

MaxDB kann unter denselben Lizenzen benutzt werden, die für andere von MySQL AB vertriebene Produkte gelten. Es ist daher unter der Lizenz GNU General Public License sowie einer kommerziellen Lizenz erhältlich. Weitere Informationen zur Lizenzierung finden Sie unter http://www.mysql.com/company/legal/licensing/.

MySQL AB bietet technischen Support für Nicht-SAP-Kunden. Der Support ist in verschiedenen Stufen erhältlich (Basic, Silver, Gold), die vom unbegrenzten E-Mail- und Web-Support bis hin zum 24×7-Telefon-Support für geschäftskritische Anwendungen reichen.

MySQL AB bietet auch Lizenzen und Support für MaxDB an, wenn es mit SAP-Applikationen wie SAP NetWeaver und der mySAP-Business-Suite eingesetzt wird. Für weitere Informationen zu Lizenzen und Support gemäß Ihren Anforderungen setzen Sie sich bitte mit MySQL AB in Verbindung (http://www.mysql.com/company/contact/).

Consulting und Schulungen sind ebenfalls erhältlich. MySQL gibt in regelmäßigen Abständen Kurse. Eine Liste finden Sie unter http://www.mysql.com/training/.

### 1.5.5. Unterschiede zwischen MaxDB und MySQL

MaxDB ist die SAP-zertifizierte Datenbank von MySQL AB. Der MaxDB-Datenbankserver ergänzt das Produktport von MySQL AB. Einige Features von MaxDB sind bei MySQL Server nicht erhältlich und umgekehrt.

Folgende Liste fasst die Hauptunterschiede zwischen MaxDB und MySQL zusammen, wobei kein Anspruch auf Vollständigkeit besteht:

- MaxDB läuft als Client-Server-System, während MySQL darüber hinaus auch als eingebettetes System laufen kann.

- MaxDB läuft nicht auf allen von MySQL unterstützten Plattformen.

- MaxDB verwendet ein proprietäres Netzwerkprotokoll für die Client-Server-Kommunikation. MySQL benutzt entweder TCP/IP (mit oder ohne SSL-Verschlüsselung), Sockets (unter Unix-ähnlichen Systemen) oder Named Pipes und Shared Memory (unter Systemen der Windows-NT-Familie).

- MaxDB unterstützt gespeicherte Prozeduren und Funktionen. MySQL unterstützt diese ab Version 5.0 ebenfalls. MaxDB unterstützt die Programmierung von Triggern über eine SQL-Erweiterung. MySQL unterstützt Trigger ab Version 5.0. MaxDB enthält einen Debugger für Stored-Procedure-Sprachen, kann Trigger verschachteln und unterstützt mehrere Trigger pro Aktion und Zeile.

- MaxDB wird mit textbasierten, grafischen und webbasierten Benutzerschnittstellen ausgeliefert. MySQL wird nur mit textbasierten Schnittstellen ausgeliefert, während grafische Benutzerwerkzeuge wie MySQL Query Browser und MySQL Administrator getrennt von den Hauptdistributionen zur Verfügung stehen. Webbasierte Schnittstellen für MySQL werden von Drittanbietern zur Verfügung gestellt.

- MaxDB unterstützt eine Reihe von Programmierschnittstellen, die auch von MySQL unterstützt werden. Zur Entwicklung mit MaxDB stehen folgende Schnittstellen zur Verfügung: Der MaxDB ODBC-Treiber, SQL Database Connectivity (SQLDBC), JDBC-Treiber, Perl- und Python-Module und eine MaxDB PHP-Extension, die den Zugriff auf MaxDB mittels PHP erlaubt. Schnittstellen von Drittanbietern: Unterstützung für OLE DB, ADO, DAO, RDO und .NET über ODBC. MaxDB unterstützt eingebettetes SQL mit C/C++.

- MaxDB enthält Verwaltungsfeatures, die MySQL nicht hat: Auftragsplanung nach Zeit (in MySQL ab Version 5.1 enthalten), Ereignis und Alarm sowie das Senden von Nachrichten an einen Datenbankverwalter, geregelt durch Alarmschwellen (Thresholds).

### 1.5.6. Interoperabilität zwischen MaxDB und MySQL

MaxDB und MySQL sind unabhängige Datenbankverwaltungssysteme. Beide Systeme können über Datenaustausch interagieren. Um Daten zwischen MaxDB und MySQL auszutauschen, können Sie entweder die jeweiligen Export- und Importwerkzeuge der Systeme oder den Synchronisationsmanager von MaxDB verwenden. Die Verwendung der Import- und Exportwerkzeuge ist für gelegentlichen, manuell durchgeführten Datenabgleich gedacht. Der Synchronisationsmanager von MaxDB dagegen bietet schnelle, automatische Datentransfer-Möglichkeiten.

Der MaxDB Loader kann zum Export von Daten und Objektdefinitionen verwendet werden. Der Loader kann Daten im MaxDB-internen, im binären oder im Textformat (CSV) exportieren. Ins Textformat exportierte Daten können in MySQL mittels des Clientprogramms mysqlimport importiert werden. Um Daten aus MySQL zu exportieren, können Sie entweder mysqldump verwenden, um `INSERT`-Anweisungen zu erzeugen, oder `SELECT ... INTO OUTFILE`, um eine Textdatei (CSV) zu schreiben. Diese Daten können dann mit dem MaxDB Loader importiert werden.

Objektdefinitionen können zwischen den Systemen mittels MaxDB Loader und dem MySQL-Werzeug mysqldump ausgetauscht werden. Weil die SQL-Dialekte beider Systeme sich leicht unterscheiden und MaxDB Features aufweist, die momentan von MySQL nicht unterstützt werden (beispielsweise SQL-Constraints), empfehlen wir, Definitionsdateien per Hand abzugleichen. Das Werkzeug mysqldump stellt die Option `--compatible=maxdb` zur Verfügung, die Ausgaben erzeugt, die sich leichter nach MaxDB portieren lassen.

Der Synchronisationsmanager von MaxDB steht ab Version 7.6 zur Verfügung. Er unterstützt das Erzeugen von asynchronen Replikationsszenarien zwischen mehreren MaxDB-Instanzen. Es sind jedoch auch darüber hinausgehende Features zur Interoperabilität geplant, die es dem Synchronisationsmanager erlauben sollen, zu und von einem MySQL Server zu replizieren.

### 1.5.7. Links zu MaxDB

Die Hauptseite für Informationen zu MaxDB ist http://www.mysql.com/products/maxdb. Hier finden Sie detaillierte Informationen zu den Features des MaxDB- Datenbanksystems und Links zur verfügbaren Dokumentation.

Das MySQL Referenzhandbuch enthält keinerlei MaxDB-Dokumentation mit Ausnahmen der in diesem Abschnitt gegebenen Einführung. MaxDB hat seine eigene Dokumentation, genannt MaxDB-Bibliothek, die sich hier befindet: http://dev.mysql.com/doc/maxdb/index.html.

MySQL AB unterhält eine Community-Mailingliste zu MaxDB: http://lists.mysql.com/maxdb, auf der sich neben lebhaften Beiträgen der Community auch Postings der Kernentwickler finden. Produktankündigungen werden ebenfalls an diese Liste geschickt.

Ein Webforum zu MaxDB ist verfügbar unter http://forums.mysql.com/. Im Forum werden vorrangig Fragen zu MaxDB angesprochen, die sich nicht auf SAP-Applikationen beziehen.

## 1.6. MySQL-Roadmap

Dieser Abschnitt enthält eine Momentaufnahme des MySQL-Entwicklungsfahrplans einschließlich verschiedener wichtiger Funktionen, die in diversen MySQL-Releases implementiert wurden bzw. für diese vorgesehen sind. Nachfolgend finden Sie Informationen zu allen Release-Serien.

Die aktuelle Release-Serie ist MySQL 5.0. Die für den Einsatz in Produktionsumgebungen erforderliche Stabilität wurde für MySQL 5.0.15 (Freigabe im Oktober 2005) festgestellt. Die vorherige Release-Serie war MySQL 4.1. Die für den Einsatz in Produktionsumgebungen erforderliche Stabilität wurde für MySQL 4.1.7 (Freigabe im Oktober 2004) festgestellt. „Produktionsstatus“ bedeutet, dass die Entwicklung bei den Versionen 5.0 und 4.1 zukünftig auf die Fehlerbereinigung beschränkt ist. Bei den älteren MySQL-Serien 4.0 und 3.23 werden nur noch kritische Fehler behoben.

Die aktive MySQL-Entwicklung betrifft derzeit die MySQL-Release-Serien 5.0 und 5.1. Neue Funktionen werden lediglich bei Version 5.1 implementiert.

Bevor Sie von einer Release-Serie auf die nächste aktualisieren, beachten Sie die Hinweise in Abschnitt 2.10, „MySQL aktualisieren (Upgrade/Downgrade)“.

Die meistgewünschten Funktionen und die Versionen, in denen sie implementiert werden bzw. für die ihre Implementierung vorgesehen ist, werden in folgender Tabelle zusammengefasst.

Funktion | MySQL-Serie
Fremdschlüssel | 3.23 (für die `InnoDB`-Speicher-Engine)
Unions | 4.0
Unterabfragen | 4.1
R-Trees | 4.1 (für die `MyISAM`-Speicher-Engine)
Gespeicherte Prozeduren | 5.0
Sichten | 5.0
Cursor | 5.0
XA-Transaktionen | 5.0
Fremdschlüssel | 5.2 (implementiert in 3.23 für `InnoDB`)
Trigger | 5.0 und 5.1
Partitionierung | 5.1
Pluggable Storage Engine-API | 5.1
Datensatzbasierte Replikation | 5.1

### 1.6.1. Was ist neu in MySQL 5.1?

Die folgenden Funktionen wurden in MySQL 5.1 implementiert. Weitere Detailinformationen werden wir im Zuge der Weiterentwicklung von MySQL 5.1 ergänzen.

- Partitionierung: Diese Funktionalität erlaubt die Verteilung von Teilen einzelner Tabellen über ein Dateisystem. Die entsprechenden Regeln können bei Erstellung der Tabelle konfiguriert werden. Verschiedene Teile einer Tabelle werden also als separate Tabellen an verschiedenen Positionen abgelegt, die partitionierte Tabelle präsentiert sich dem Benutzer jedoch weiterhin als eine einzige Tabelle. Weitere Informationen zu dieser Funktionalität finden Sie in Kapitel 17, Partitionierung (Autor: Mikael Ronström).

- Plug-In-API: MySQL 5.1 unterstützt eine sehr flexible Plug-In-API, die das Laden und Entladen verschiedener Komponenten während der Laufzeit gestattet, ohne dass der Server neu gestartet werden müsste. Zwar sind die Arbeiten daran noch nicht abgeschlossen, aber die Plug-In-Volltext-Parser sind ein erster Schritt in diese Richtung. Hiermit können Benutzer eigene Eingabefilter für indizierten Text implementieren und so eine Volltextsuche für beliebige Daten (z. B. PDF-Dateien oder andere Dokumentformate) ermöglichen. Ein dem Parser vorgeschaltetes Volltext-Plug-In führt die eigentliche Verarbeitung und Extraktion des Texts durch und übergibt diesen dann an die in MySQL integrierte Volltextsuche (Autor: Sergey Vojtovich).

- Der Instanzen-Manager (IM) bietet nun einige neue Funktionen:

  - `SHOW `instance_name` LOG FILES` listet alle von der Instanz verwendeten Logdateien auf (Autor: Petr Chardin).

  - `SHOW `instance_name` LOG {ERROR | SLOW | GENERAL} `size`` ruft einen Teil der angegebenen Logdatei ab (Autor: Petr Chardin).

  - `SET `instance_name`.`option_name`=`option_value`` setzt eine Option auf den angegebenen Wert und schreibt sie in die Konfigurationsdatei. Weitere Informationen zu diesen neuen Befehlen finden Sie unter Abschnitt 5.5, „mysqlmanager — Der MySQL Instance Manager“ (Autor: Petr Chardin).

## 1.7. Informationsquellen zu MySQL

Dieser Abschnitt listet zusätzliche Informationsquellen auf, die für Sie hilfreich sein können. Dies sind etwa die MySQL-Mailinglisten und Benutzerforen sowie IRC-Kanäle.

### 1.7.1. Die MySQL-Mailinglisten

Dieser Abschnitt stellt die MySQL-Mailinglisten vor und enthält Hinweise zur Benutzung dieser Listen. Wenn Sie eine Mailingliste bestellen, erhalten Sie alle Beiträge zu dieser Liste als E-Mails. Sie können auch eigene Fragen (und Antworten) an die Liste schicken.

Um eine der in diesem Abschnitt aufgeführten Listen zu bestellen bzw. zu kündigen, besuchen Sie die Seite http://lists.mysql.com/. Bei den meisten Listen können Sie die reguläre Version, bei der jeder Beitrag einzeln als Mail gesendet wird, oder eine Digest-Version auswählen, wobei Sie einmal täglich eine lange Mail mit allen Beiträgen des Tages erhalten.

Bitte senden Sie bei Fragen zu Bestellung oder Kündigung einer Liste keine Mitteilungen an die Liste selbst, denn auch diese werden automatisch an tausende anderer Benutzer weitergeschickt.

An Ihrem Standort haben vielleicht schon viele Benutzer eine MySQL-Mailingliste abonniert. Sollte dies der Fall sein, dann wird am Standort womöglich eine lokale Mailingliste betrieben, sodass Mitteilungen, die von `lists.mysql.com` an Ihren Standort geschickt werden, an diese lokale Liste weitergeleitet werden. Wenden Sie sich in diesem Fall an Ihren Systemadministrator, damit dieser Sie zur lokalen MySQL-Liste hinzufügt bzw. aus dieser entfernt.

Wenn Sie wollen, dass die Daten einer Mailingliste in Ihrem E-Mail-Programm in ein anderes Postfach geleitet werden, erstellen Sie einen Filter, der eingehende Mails nach den Kopfdaten (Headern) sortiert. Sie können die Header `List-ID:` oder `Delivered-To:` zur Identifizierung von Mitteilungen einer MySQL-Liste verwenden.

Die folgenden MySQL-Mailinglisten sind vorhanden:

- `announce`

  Diese Liste ist für Ankündigungen neuer MySQL-Versionen und zugehöriger Programme vorgesehen. Das Aufkommen ist bei dieser Liste gering. Sie sollte von allen MySQL-Benutzern abonniert werden.

- `mysql`

  Dies ist die wichtigste Liste für allgemeine Diskussionen zu MySQL. Bitte beachten Sie, dass einige Themen besser in den spezialisierteren Listen behandelt werden. Wenn Sie eine Mitteilung an die falsche Liste schicken, erhalten Sie unter Umständen keine Antwort.

- `bugs`

  Diese Liste ist für Benutzer vorgesehen, die bezüglich aller Probleme, die seit dem letzten MySQL-Release gemeldet wurden, auf dem neuesten Stand bleiben oder sich aktiv an der Suche und Behebung von Bugs beteiligen wollen. Siehe auch Abschnitt 1.8, „Wie man Bugs oder Probleme meldet“.

- `internals`

  Diese Liste ist für Benutzer vorgesehen, die am MySQL-Code arbeiten. Sie ist auch das Forum für Diskussionen zur MySQL-Entwicklung und zur Verbreitung von Patches.

- `mysqldoc`

  Diese Liste ist für Benutzer vorgesehen, die an der MySQL-Dokumentation arbeiten. Dies sind beispielsweise Mitarbeiter von MySQL AB oder Übersetzer.

- `benchmarks`

  Diese Liste ist für jeden gedacht, der sich für Fragen der Leistungsfähigkeit interessiert. Die Diskussionen drehen sich in erster Linie um die Leistung von Datenbanken (wobei man sich nicht auf MySQL beschränkt), aber auch andere Kategorien – z. B. die Leistungsfähigkeit von Kerneln, Datei- oder Festplattensystemen usw. – werden hier behandelt.

- `packagers`

  Diese Liste ist für Diskussionen gedacht, bei denen es um das Packen und Vertreiben von MySQL geht. Dies ist das Forum, in dem für die Distribution Zuständige Ideen zum Packen von MySQL und zu der Frage austauschen können, wie man gewährleistet, dass „Look and Feel“ von MySQL auf allen unterstützten Plattformen und Betriebssystemen so ähnlich wie möglich sind.

- `java`

  Diese Liste ist für Diskussionen über den MySQL Server und Java vorgesehen. Hier werden meistens JDBC-Treiber wie etwa MySQL Connector/J diskutiert.

- `win32`

  Diese Liste ist für alle Themen reserviert, die den Betrieb der MySQL-Software auf Microsoft-Betriebssystemen wie Windows 9x, Me, NT, 2000, XP und 2003 betreffen.

- `myodbc`

  Diese Liste behandelt Themen im Zusammenhang mit der Verbindungsherstellung zum MySQL Server über ODBC.

- `gui-tools`

  Diese Liste ist für alle Themen vorgesehen, die GUI-Tools (grafische Oberflächen) für MySQL bereitstellen, z. B. `MySQL Administrator` und `MySQL Query Browser`.

- `cluster`

  Bei dieser Liste dreht sich alles um MySQL Cluster.

- `dotnet`

  Diese Liste ist für Diskussionen über den MySQL Server und die .NET-Plattform vorgesehen. Es geht dabei in erster Linie um MySQL Connector/Net.

- `plusplus`

  Diese Liste behandelt alle Themen in Zusammenhang mit der Programmierung unter Verwendung der C++-API für MySQL.

- `perl`

  Dies ist eine Liste, bei der Themen zum Bereich der Perl-Unterstützung für MySQL mit `DBD::mysql` diskutiert werden.

Wenn Sie über eine MySQL-Mailingliste oder ein Forum keine befriedigende Antwort auf Ihre Frage erhalten, besteht eine weitere Option im kostenpflichtigen Support durch MySQL AB. Auf diese Weise erhalten Sie direkten Kontakt zu den MySQL-Entwicklern.

Die folgende Tabelle enthält einige MySQL-Mailinglisten in anderen Sprachen als Englisch. Diese Listen werden jedoch nicht von MySQL AB betrieben.

- ``<mysql-france-subscribe@yahoogroups.com>``

  Eine französischsprachige Mailingliste.

- ``<list@tinc.net>``

  Eine koreanischsprachige Mailingliste. Sie bestellen sie, indem Sie den Befehl `subscribe mysql ihre@email.adresse` in einer Mail an die Liste schicken.

- ``<mysql-de-request@lists.4t2.com>``

  Eine deutschsprachige Mailingliste. Sie bestellen sie, indem Sie den Befehl `subscribe mysql-de ihre@email.adresse` in einer Mail an die Liste schicken. Weitere Informationen zu dieser Mailingliste finden Sie unter http://www.4t2.com/mysql/.

- ``<mysql-br-request@listas.linkway.com.br>``

  Eine portugiesischsprachige Mailingliste. Sie bestellen sie, indem Sie den Befehl `subscribe mysql-br ihre@email.adresse` in einer Mail an die Liste schicken.

- ``<mysql-alta@elistas.net>``

  Eine spanischsprachige Mailingliste. Sie bestellen sie, indem Sie den Befehl `subscribe mysql ihre@email.adresse` in einer Mail an die Liste schicken.

#### 1.7.1.1. Richtlinien für die Benutzung der MySQL-Mailinglisten

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.

### 1.7.2. MySQL-Community-Support in den MySQL-Foren

Die Foren unter http://forums.mysql.com sind eine wichtige Quelle für die Benutzergemeinschaft. Es gibt eine ganze Reihe von Foren, die in die folgenden Kategorien fallen:

- Migration

- MySQL verwenden

- MySQL Connectors

- Programmiersprachen

- Tools

- Anwendungen von Drittanbietern

- Speicher-Engines

- MySQL-Technologie

- SQL-Standards

- Business

### 1.7.3. Unterstützung für die MySQL-Community auf Internet Relay Chat (IRC)

Neben den verschiedenen MySQL-Mailinglisten und -Foren finden Sie erfahrene Mitglieder der Gemeinschaft im Internet Relay Chat (IRC). Die folgenden Netzwerke und Kanäle sind die besten, die wir derzeit kennen:

freenode (Serverinformationen unter http://www.freenode.net/)

- `#mysql` ist in erster Linie für MySQL-spezifische Fragen gedacht, aber auch allgemeine Fragen zum SQL-Komplex sind willkommen. Auch Fragen zu PHP, Perl oder C in Verbindung mit MySQL sind hier häufig zu finden.

Wenn Sie nach einer IRC-Clientsoftware suchen, um eine Verbindung mit einem IRC-Netzwerk herzustellen, dann werfen Sie einen Blick auf `xChat` (http://www.xchat.org/). X-Chat (unter GPL-Lizenz) ist für Unix und für Windows-Plattformen erhältlich. (Einen kostenlosen Build von X-Chat finden Sie unter http://www.silverex.org/download/.)

## 1.8. Wie man Bugs oder Probleme meldet

Bevor Sie einen Bugreport zu einem Problem einreichen, stellen Sie zunächst sicher, dass es sich wirklich um einen Bug handelt und dass dieser nicht bereits gemeldet wurde:

- Beginnen Sie mit der Suche im MySQL-Online-Manual unter http://dev.mysql.com/doc/. Wir versuchen, das Manual aktuell zu halten, indem wir es häufig mit Lösungen zu neu gefundenen Problemen aktualisieren. Die Änderungshistorie (http://dev.mysql.com/doc/mysql/en/news.html) kann besonders nützlich sein, da es durchaus möglich ist, dass eine neuere Version eine Lösung zu Ihrem Problem enthält.

- Wenn beim Parsen einer SQL-Anweisung ein Fehler auftritt, überprüfen Sie Ihre Syntax bitte sorgfältig. Wenn Sie keinen Fehler erkennen können, ist es sehr wahrscheinlich, dass Ihre gegenwärtige Version von MySQL Server die verwendete Syntax nicht unterstützt. Wenn Sie die aktuelle Version verwenden und das Manual die von Ihnen verwendete Syntax nicht behandelt, dann unterstützt MySQL Server Ihre Anweisung nicht. In diesem Fall bestehen Ihre Möglichkeiten darin, die Syntax selbst zu implementieren oder eine E-Mail an `<licensing@mysql.com>` zu senden und darin um ein Angebot für eine Implementierung zu bitten.

  Wenn das Manual die von Ihnen verwendete Syntax behandelt, aber Sie mit einer älteren Version von MySQL Server arbeiten, überprüfen Sie in der MySQL-Änderungshistorie, wann die Syntax implementiert wurde. In diesem Fall können Sie auf eine neuere Version von MySQL Server aktualisieren.

- Informationen zur Lösung einiger häufiger Probleme finden Sie unter Anhang A, Probleme und häufig auftretende Fehler.

- Durchsuchen Sie die Bugdatenbank unter http://bugs.mysql.com/ und überprüfen Sie, ob der Bug gemeldet und ggf. behoben wurde.

- Durchsuchen Sie die Archive der MySQL-Mailinglisten unter http://lists.mysql.com/. Siehe auch Abschnitt 1.7.1, „Die MySQL-Mailinglisten“.

- Sie können auch über http://www.mysql.com/search/ alle Webseiten (einschließlich des Manuals) durchsuchen, die sich auf der Website von MySQL AB befinden.

Wenn Sie im Manual, der Bugdatenbank oder den Archiven der Mailinglisten keine Antwort finden, wenden Sie sich an Ihren lokalen MySQL-Fachmann. Erhalten Sie auch dort keine Antwort auf Ihre Frage, dann melden Sie den Bug bitte unter Beachtung der folgenden Verhaltensregeln.

Die normale Vorgehensweise zur Meldung von Bugs besteht in einem Besuch auf http://bugs.mysql.com/. Dies ist die Adresse unserer Bugdatenbank. Diese Datenbank ist öffentlich und kann von jedem gelesen und durchsucht werden. Wenn Sie sich am System anmelden, können Sie neue Meldungen eingeben. Haben Sie keinen Webzugang, dann können Sie mit dem Skript mysqlbug einen Bugreport erstellen. Das Skript ist am Ende dieses Abschnitts beschrieben.

Bugs, die in die Bugdatenbank unter http://bugs.mysql.com/ eingetragen sind und in einem gegebenen Release behoben wurden, sind in der Änderungshistorie vermerkt.

Wenn Sie einen sensiblen Sicherheitsbug in MySQL gefunden haben, können Sie eine E-Mail an `<security@mysql.com>` schicken.

Wenn Sie Probleme mit anderen Benutzern diskutieren wollen, können Sie zu diesem Zweck eine der MySQL-Mailinglisten verwenden. Abschnitt 1.7.1, „Die MySQL-Mailinglisten“.

Das Verfassen eines Bugreports erfordert Geduld. Wenn Sie dies aber zuallererst tun, sparen Sie sowohl sich selbst als auch uns Zeit. Ein guter Bugreport enthält einen vollständigen Testfall für den Bug, welcher es uns mit hoher Wahrscheinlichkeit ermöglichen wird, ihn bereits im nächsten Release zu beheben. Dieser Abschnitt soll Ihnen dabei helfen, Ihren Bugreport korrekt zu formulieren, sodass Sie keine Zeit mit Dingen verschwenden, die uns nur wenig oder gar nicht helfen. Bitte lesen Sie diesen Abschnitt aufmerksam durch und stellen Sie sicher, dass alle hier beschriebenen Angaben in Ihrem Report enthalten sind.

Sie sollten das Problem bevorzugt mit der aktuellen Produktions- oder Entwicklungsversion von MySQL Server überprüfen, bevor Sie den Report absenden. Der Bug sollte sich problemlos reproduzieren lassen, indem einfach der Befehl `mysql test < script_file` für Ihren Testfall ausgeführt oder das Shell- oder Perl-Skript gestartet wird, das Sie dem Bugreport hinzufügen. Für jeden Bug, den wir reproduzieren können, stehen die Chancen einer Behebung im nächsten MySQL-Release gut.

Am hilfreichsten ist es, wenn eine gute Beschreibung des Problems dem Bugreport beiliegt. Das bedeutet: Geben Sie ein gutes Beispiel für alles an, was Sie taten, als das Problem auftrat, und beschreiben Sie möglichst detailliert das Problem selbst. Die besten Reports sind diejenigen, die eine vollständige Beschreibung enthalten, wie der Bug oder das Problem reproduziert werden können. Siehe auch Abschnitt E.1.6, „Erzeugen eines Testfalls, wenn Sie Tabellenbeschädigung feststellen“.

Bedenken Sie, dass wir zwar einen Report bearbeiten können, der zu viele Angaben enthält, nicht aber einen solchen, der zu wenig Informationen umfasst. Es kommt häufig vor, dass Tatsachen weggelassen werden, weil der Einreicher annimmt, dass wir das Problem kennen und die Details keine Rolle spielen. Eine Faustregel, der Sie folgen können, lautet: Wenn Sie im Zweifel sind, ob Sie etwas angeben wollen, dann geben Sie es lieber an. Es geht schneller und ist weniger mühsam, ein paar Zeilen mehr in Ihren Report zu schreiben, als länger auf die Antwort warten zu müssen, weil wir bei Ihnen Angaben erfragen müssen, die im eingereichten Bugreport nicht enthalten waren.

Die meistgemachten Fehler in Bugreports bestehen darin, dass (a) die Versionsnummer der verwendeten MySQL-Distribution nicht enthalten und (b) die Plattform, auf der der MySQL Server installiert ist, nicht vollständig (einschließlich der Angaben zu Typ und Versionsnummer der Plattform) beschrieben ist. Dies sind extrem wichtige Informationen, und in 99 von 100 Fällen ist der Bugreport ohne sie wertlos. Sehr oft erhalten wir Fragen wie „Warum funktioniert das bei mir nicht?“. Dann stellen wir fest, dass die angeforderte Funktionalität in der betreffenden MySQL-Version gar nicht implementiert war oder dass ein in einem Report beschriebener Bug in einer neueren MySQL-Version bereits behoben ist. Fehler sind häufig plattformspezifisch. In solchen Fällen ist es praktisch unmöglich für uns, irgendetwas zu beheben, wenn wir weder das Betriebssystem noch die Versionsnummer der Plattform kennen.

Wenn Sie MySQL aus dem Quellcode kompiliert haben, denken Sie bitte auch daran, Angaben zu Ihrem Compiler hinzuzufügen, sofern dies für das Problem relevant ist. Häufig finden Benutzer Bugs in Compilern und glauben dann, dass das Problem MySQL-spezifisch ist. Die meisten Compiler werden fortlaufend weiterentwickelt und von Version zu Version besser. Um zu ermitteln, ob Ihr Problem von Ihrem Compiler abhängt, müssen wir wissen, welchen Compiler Sie verwendet haben. Beachten Sie, dass jedes Kompilierungsproblem als Bug betrachtet und entsprechend gemeldet werden sollte.

Wenn ein Programm eine Fehlermeldung erzeugt, ist es sehr wichtig, auch diese Meldung in Ihrem Report zu erwähnen. Wenn wir versuchen, Erkundigungen in den Archiven einzuziehen, dann ist es am besten, wenn Sie die Fehlermeldung exakt so angeben, wie das Programm sie erzeugt hat. (Beachten Sie im Zweifelsfall auch die Groß-/Kleinschreibung.) Am besten kopieren Sie die gesamte Fehlermeldung über die Zwischenablage in Ihren Report. Versuchen Sie bitte nicht, die Fehlermeldung aus dem Gedächtnis zu rekonstruieren.

Wenn Sie ein Problem in Zusammenhang mit Connector/ODBC (MyODBC) haben, versuchen Sie bitte, eine Trace-Datei zu erzeugen, und schicken diese mit Ihrem Report. Siehe auch Abschnitt 25.1.7.2, „Melden von MyODBC-Problemen und -Fehlern“.

Wenn Ihr Report lange Abfrageausgabezeilen aus Testfällen enthält, die Sie mit dem Befehlszeilen-Tool mysql ausgeführt haben, dann können Sie die Leserlichkeit der Ausgabe mit der Option `--vertical` oder dem Abschlusszeichen `\G` erhöhen. Das weiter unten folgende Beispiel für `EXPLAIN SELECT` demonstriert die Verwendung von `\G`.

Bitte legen Sie Ihrem Report die folgenden Angaben bei:

- Die Versionsnummer der von Ihnen verwendeten MySQL-Distribution (z. B. MySQL 5.0.19). Die Versionsnummer ermitteln Sie durch Ausführen von mysqladmin version. Das Programm mysqladmin finden Sie im Verzeichnis `bin` im MySQL-Installationsverzeichnis.

- Den Hersteller und das Modell des Computers, auf dem das Problem aufgetreten ist.

- Name und Version des Betriebssystems. Wenn Sie mit Windows arbeiten, erhalten Sie Namen und Versionsnummer, indem Sie auf das Arbeitsplatz-Symbol doppelklicken und dann den Eintrag „Hilfe/Über Windows“ auswählen. Bei den meisten UNIX-Derivaten gelangen Sie an diese Angaben, indem Sie den Befehl `uname -a` ausführen.

- In bestimmten Fällen ist die Menge des (physischen und virtuellen) Speichers relevant. Geben Sie diese Werte im Zweifelsfall auch an.

- Wenn Sie eine Quelldistribution der MySQL-Software verwenden, geben Sie Namen und Versionsnummer des verwendeten Compilers an. Im Falle einer Binärdistribution nennen Sie den Distributionsnamen.

- Tritt das Problem während der Kompilierung auf, dann fügen Sie die exakten Fehlermeldungen sowie ein paar Zeilen Kontext im Bereich des problematischen Codes in der Datei hinzu, in dem der Fehler auftritt.

- Wenn mysqld abstürzt, sollten Sie auch die Anweisung angeben, mit der mysqld zum Absturz gebracht wurde. Diese Information erhalten Sie normalerweise, wenn Sie mysqld mit aktiviertem Abfragelog starten und die Logdatei überprüfen, nachdem mysqld abgestürzt ist. Siehe auch Abschnitt E.1.5, „Logdateien benutzen, um Ursachen für Fehler in mysqld zu finden“.

- Wenn eine Datenbanktabelle mit dem Problem in Zusammenhang steht, geben Sie die Ausgabe der Anweisung `SHOW CREATE TABLE `db_name`.`tbl_name`` im Bugreport an. Dies stellt eine sehr einfache Möglichkeit dar, die Definition einer beliebigen Tabelle in der Datenbank zu ermitteln. Mithilfe dieser Information können wir die Situation, in der das Problem bei Ihnen auftrat, auf unseren Systemen nachstellen.

- Bei leistungsspezifischen Bugs oder Problemen mit `SELECT`-Anweisungen sollten Sie außerdem die Ausgabe von `EXPLAIN SELECT ...` und zumindest die Anzahl der Datensätze angeben, die die `SELECT`-Anweisung erzeugt. Ferner hinzufügen sollten Sie die Ausgabe von `SHOW CREATE TABLE `tbl_name`` für jede betroffene Tabelle. Je mehr Angaben Sie über die Umstände machen, desto größer ist die Wahrscheinlichkeit, dass wir Ihnen helfen können.

  Nachfolgend finden Sie ein Beispiel für einen sehr guten Bugreport. Die Anweisungen werden mit dem Befehlszeilen-Tool mysql ausgeführt. Beachten Sie die Verwendung des Abschlusszeichens `\G` bei Anweisungen, die andernfalls sehr lange, schwierig zu lesende Ausgabezeilen erzeugen würden.

      mysql> SHOW VARIABLES; mysql> SHOW COLUMNS FROM ...\G <output from SHOW COLUMNS> mysql> EXPLAIN SELECT ...\G <output from EXPLAIN> mysql> FLUSH STATUS; mysql> SELECT ...; <A short version of the output from SELECT, including the time taken to run the query> mysql> SHOW STATUS; <output from SHOW STATUS>

- Wenn während der Ausführung von mysqld ein Bug oder Problem auftritt, dann versuchen Sie, ein Eingabeskript hinzuzufügen, welches die Anomalie reproduziert. Dieses Skript sollte alle erforderlichen Quellcodedateien enthalten. Je exakter das Skript die betreffende Situation reproduzieren kann, umso besser. Wenn Sie einen reproduzierbaren Test erstellen können, sollten Sie diesen als Anhang an den Bugreport anhängen.

  Können Sie kein Skript erstellen, dann sollten Sie Ihrem Report zumindest die Ausgabe von mysqladmin variables extended-status processlist hinzufügen, damit wir einige Anhaltspunkte dazu erhalten, wie Ihr System arbeitet.

- Können Sie keinen Testfall mit nur wenigen Datensätzen erstellen oder ist die Testtabelle zu groß, um in den Bugreport eingefügt werden zu können (d. h., sie umfasst mehr als zehn Datensätze), dann sollten Sie Ihre Tabellen mit mysqldump speichern und eine `README`-Datei erstellen, die Ihr Problem beschreibt. Erstellen Sie ein komprimiertes Archiv Ihrer Dateien mithilfe von tar und gzip oder zip und übertragen Sie das Archiv dann via FTP an ftp://ftp.mysql.com/pub/mysql/upload/. Tragen Sie das Problem danach in unsere Bugdatenbank unter http://bugs.mysql.com/ ein.

- Wenn Sie der Ansicht sind, dass der MySQL Server ein merkwürdiges Ergebnis für die Anweisung erzeugt, fügen Sie nicht nur dieses, sondern auch Ihre Ansicht bezüglich des von Ihnen erwarteten Ergebnisses und eine Beschreibung der Grundlage dieser Ansicht hinzu.

- Wenn Sie ein Beispiel des Problems angeben, sollten Sie am besten Tabellennamen, Variablennamen usw. verwenden, die in Ihrer tatsächlichen Situation zum Einsatz kommen, statt neue Namen einzuführen. Das Problem könnte auch mit dem Namen einer Tabelle oder Variablen zusammenhängen. Solche Fälle mögen selten sein, aber besser ist es, auf der sicheren Seite zu stehen. Schließlich sollte es für Sie einfacher sein, ein Beispiel anzugeben, das Ihre tatsächlichen Umstände verwendet, und für uns ist dies in jedem Fall besser. Wenn Sie wollen, dass bestimmte Daten im Bugreport für Dritte unsichtbar bleiben, können Sie ihn via FTP an ftp://ftp.mysql.com/pub/mysql/upload/ übertragen. Sind die Daten wirklich derart geheim, dass Sie sie noch nicht einmal uns zeigen wollen, dann können Sie auch ein Beispiel unter Verwendung anderer Namen erstellen; dies stellt allerdings nur den letzten Ausweg dar.

- Fügen Sie, sofern möglich, alle Optionen an, die Sie für die betreffenden Programme angegeben hatten. Geben Sie etwa die Optionen an, die Sie beim Start des Servers mysqld verwenden, sowie auch solche, die Sie bei der Ausführung von MySQL-Clientprogrammen verwendet haben. Die Optionen für Programme wie mysqld und mysql sowie für das Skript configure sind für die Behebung von Problemen häufig unentbehrlich, und es kann nie schaden, sie hinzuzufügen. Wenn Ihr Problem in Zusammenhang mit einem Programm steht, das in einer Sprache wie Perl oder PHP geschrieben ist, fügen Sie bitte die Versionsnummer des Sprachprozessors sowie die Versionen aller Module an, die das Programm verwendet. Setzen Sie beispielsweise ein Perl-Skript ein, das die Module `DBI` und `DBD::mysql` benutzt, dann müssen Sie die Versionsnummern von Perl, `DBI` und `DBD::mysql` angeben.

- Bezieht sich Ihre Frage auf das Berechtigungssystem, dann führen Sie bitte die Ausgaben von mysqlaccess und mysqladmin reload sowie alle Fehlermeldungen an, die Sie beim Verbindungsversuch erhalten. Wenn Sie Ihre Berechtigungen testen, sollten Sie zunächst mysqlaccess ausführen. Nachfolgend starten Sie mysqladmin reload version und versuchen, eine Verbindung mit dem problematischen Programm herzustellen. Das Programm mysqlaccess finden Sie im Verzeichnis `bin` im MySQL-Installationsverzeichnis.

- Wenn Sie einen Patch für einen Bug haben, fügen Sie ihn hinzu. Gehen Sie aber nicht davon aus, dass wir lediglich diesen Patch benötigen oder dass wir ihn verwenden können, wenn Sie bestimmte Angaben wie etwa Testfälle weglassen, die den Bug demonstrieren, den Sie mit Ihrem Patch beheben. Unter Umständen stellen wir Probleme bei Ihrem Patch fest oder verstehen ihn überhaupt nicht. In diesem Fall können wir ihn natürlich nicht verwenden.

  Wenn wir den Zweck des Patches nicht exakt verifizieren können, verwenden wir ihn auch nicht. In diesem Fall sind Testfälle sehr hilfreich. Zeigen Sie, dass der Patch das Problem in allen Situationen behebt, die auftreten können. Können wir einen (ggf. auch seltenen) Fall ermitteln, in dem der Patch nicht funktioniert, dann ist er möglicherweise nutzlos.

- Mutmaßungen bezüglich des Wesens, der Ursache oder der Abhängigkeiten eines Bugs sind in der Regel falsch. Sogar das MySQL-Team kann solche Dinge nicht erraten, sondern muss zunächst einmal mit einem Debugger die wirkliche Ursache des Bugs ermitteln.

- Geben Sie in Ihrem Bugreport an, dass Sie das Referenzmaterial und das Mailarchiv überprüft haben, damit andere wissen, dass Sie zunächst versucht haben, das Problem selbst zu lösen.

- Wenn das Problem darin besteht, dass Ihre Daten beschädigt zu sein scheinen oder Sie Fehler erhalten, wenn Sie auf eine bestimmte Tabelle zugreifen, dann sollten Sie Ihre Tabellen zuerst überprüfen und dann versuchen, sie zu reparieren. Hierzu verwenden Sie `CHECK TABLE` und `REPAIR TABLE` oder aber myisamchk. Siehe auch Kapitel 5, Datenbankverwaltung.

  Wenn Sie Windows verwenden, überprüfen Sie bitte den Wert von `lower_case_table_names` mit dem Befehl `SHOW VARIABLES LIKE 'lower_case_table_names'`. Diese Variable beeinflusst, wie der Server die Groß-/Kleinschreibung von Datenbank- und Tabellennamen behandelt. Die Auswirkung auf einen gegebenen Wert sollte so sein wie in Abschnitt 9.2.2, „Groß-/Kleinschreibung in Namen“, beschrieben.

- Wenn Fälle beschädigter Tabellen bei Ihnen häufig auftreten, sollten Sie herausfinden, wann und warum dies passiert. In diesem Fall enthält das Fehlerlog im MySQL-Datenverzeichnis unter Umständen Informationen dazu, was geschehen ist. (Es handelt sich um die Datei mit dem Suffix `.err` im Dateinamen.) Siehe auch Abschnitt 5.12.1, „Die Fehler-Logdatei“. Bitte fügen Sie alle relevanten Angaben aus dieser Datei in Ihrem Bugreport an. Normalerweise sollte mysqld eine Tabelle niemals zum Absturz bringen, sofern es nicht während eines laufenden Updates terminiert wurde. Wenn Sie erkennen können, warum mysqld terminiert wird, dann ist es für uns viel einfacher, Ihnen einen Fix für dieses Problem zur Verfügung zu stellen. Siehe auch Abschnitt A.1, „Wie man feststellt, was Probleme verursacht“.

- Laden Sie, sofern möglich, die aktuellste Version von MySQL Server herunter und installieren Sie sie. Überprüfen Sie dann, ob Ihr Problem auf diese Weise gelöst wird. Alle Versionen der MySQL-Software wurden umfassend getestet und sollten problemlos funktionieren. Wir achten bei unseren Entwicklungen auf größtmögliche Abwärtskompatibilität, d. h., Sie sollten problemlos zwischen verschiedenen MySQL-Versionen wechseln können. Siehe auch Abschnitt 2.1.2, „Welche MySQL-Version Sie benutzen sollten“.

Wenn Sie keinen Webzugang haben und einen Bug nicht auf http://bugs.mysql.com/ melden können, erzeugen Sie mit dem Skript mysqlbug einen Bugreport (oder einen Report zu einem beliebigen anderen Problem). mysqlbug unterstützt Sie bei der Erzeugung eines Reports, denn ein Großteil der erforderlichen Informationen wird automatisch ermittelt. Sollte jedoch etwas fehlen, dann fügen Sie es Ihrer Meldung bitte hinzu. mysqlbug finden Sie im Verzeichnis `scripts` (Quelldistribution) bzw. im Verzeichnis `bin` unter Ihrem MySQL-Installationsverzeichnis (Binärdistribution).

## 1.9. Wie kompatibel zum SQL-Standard ist MySQL?

Dieser Abschnitt beschreibt das Verhältnis von MySQL zu den SQL-Standards von ANSI und ISO. MySQL weist eine Reihe von Erweiterungen gegenüber dem SQL-Standard auf; hier finden Sie Informationen darüber, welche Erweiterungen dies sind und wie Sie sie benutzen. Ferner sind Informationen zu den Funktionalitäten, die in MySQL fehlen, und dazu enthalten, wie Sie einige dieser Unterschiede umgehen können.

Der SQL-Standard wird seit 1986 fortlaufend entwickelt, und es existieren verschiedene Versionen. In diesem Handbuch bezeichnet „SQL-92“ den im Jahr 1992 veröffentlichten Standard, „SQL:1999“ die 1999 veröffentlichte Version und„SQL:2003“ die aktuelle Variante des Standards. Wendungen wie „der SQL-Standard“ oder „Standard-SQL“ werden generell zur Bezeichnung der aktuellen Version des SQL-Standards verwendet.

Eines unserer wichtigsten Anliegen in Bezug auf das Produkt besteht darin, die Kompatibilität mit dem SQL-Standard zu optimieren, ohne dabei Geschwindigkeit oder Zuverlässigkeit von MySQL zu opfern. Wir scheuen nicht davor zurück, SQL mit Erweiterungen zu ergänzen oder Nicht-SQL-Funktionalitäten zu unterstützen, wenn dies den Nutzen von MySQL Server für einen Großteil unserer Benutzer erheblich steigert. Die `HANDLER`-Schnittstelle ist ein Beispiel für diese Strategie. Siehe auch Abschnitt 13.2.3, „`HANDLER`“.

Wir werden auch weiterhin sowohl transaktionale als auch nichttransaktionale Datenbanken unterstützen, damit der unternehmenskritische Einsatz rund um die Uhr wie auch eine hohe Beanspruchung im Web- oder Protokollierungseinsatz möglich sind.

MySQL Server wurde ursprünglich für die Arbeit mit mittelgroßen Datenbanken (10 bis 100 Millionen Datensätze bzw. 100 Mbyte pro Tabelle) auf Kleincomputern entwickelt. Heute hingegen werden mit MySQL Server terabytegroße Datenbanken verarbeitet. Der Code kann aber auch in einer reduzierten Version kompiliert werden, die für mobile oder integrierte Geräte geeignet ist. Die kompakte Struktur des MySQL Servers ermöglicht Weiterentwicklungen in beiden Richtungen, ohne dass es im Source-Tree zu Konflikten kommt.

Derzeit streben wir keine Echtzeitunterstützung an, obwohl die Replikationsmerkmale von MySQL die wesentlichen Funktionalitäten bieten.

MySQL unterstützt Clustering für Hochverfügbarkeitsdatenbanken mithilfe der `NDBCluster`-Speicher-Engine. Siehe auch Kapitel 16, MySQL Cluster.

Die XML-Funktionalität wird ab MySQL 5.1 implementiert. Diese Version unterstützt den W3C XPath-Standard bereits weitgehend. Im Zuge der Fortentwicklung von MySQL planen wir, die XML-Unterstützung weiter zu optimieren.

### 1.9.1. An welche Standards hält sich MySQL?

Unser Ziel ist es, die SQL-Standards von ANSI und ISO vollständig zu unterstützen, ohne Zugeständnisse bezüglich der Geschwindigkeit oder der Qualität des Codes zu machen.

### 1.9.2. Auswahl der SQL-Modi

Der MySQL Server kann in verschiedenen SQL-Modi betrieben werden und diese Modi auf unterschiedliche Weise für verschiedene Clients anwenden. Diese Funktionalität erlaubt es jeder Anwendung, den Betriebsmodus des Servers an die eigenen Anforderungen anzupassen.

Die SQL-Modi steuern Aspekte des Serverbetriebs, z. B. welche SQL-Syntax MySQL unterstützen soll und welche Art der Datengültigkeitsprüfungen durchzuführen ist. Dies erleichtert die Verwendung von MySQL in verschiedenen Umgebungen und in Verbindung mit anderen Datenbankservern.

Sie können den SQL-Standardmodus einstellen, indem Sie mysqld mit der Option `--sql-mode="`mode_value`"` starten. Ab MySQL 4.1 können Sie den Modus auch während der Laufzeit ändern, indem Sie die Systemvariable `sql_mode` mit der Anweisung `SET [SESSION|GLOBAL] sql_mode='`mode_value`'` einstellen.

Weitere Informationen zur Einstellung des SQL-Modus finden Sie in Abschnitt 5.2.5, „Der SQL-Modus des Servers“.

### 1.9.3. MySQL im ANSI-Modus laufen lassen

Sie können mysqld mithilfe der Startoption `--ansi` zur Ausführung im ANSI-Modus anweisen. Die Ausführung des Servers im ANSI-Modus entspricht dem Serverstart mit den folgenden Optionen:

    --transaction-isolation=SERIALIZABLE --sql-mode=ANSI

Ab MySQL 4.1.1 können Sie den gleichen Effekt während der Laufzeit erzielen, indem Sie die folgenden beiden Anweisungen ausführen:

    SET GLOBAL TRANSACTION ISOLATION LEVEL SERIALIZABLE;
    SET GLOBAL sql_mode = 'ANSI';

Sie können wie folgt überprüfen, dass das Einstellen der Systemvariablen `sql_mode`auf `'ANSI'` alle für den ANSI-Modus relevanten SQL-Modusoptionen aktiviert:

    mysql> SET GLOBAL sql_mode='ANSI';
    mysql> SELECT @@global.sql_mode;
            -> 'REAL_AS_FLOAT,PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE,ANSI'

Beachten Sie, dass die Ausführung des Servers im ANSI-Modus mithilfe der Option `--ansi` nicht ganz zum gleichen Ergebnis führt wie die Einstellung `'ANSI'` für den SQL-Modus. Die Option `--ansi` betrifft den SQL-Modus und stellt ferner die Stufe der Transaktionsisolierung ein. Vom Einstellen des SQL-Modus auf `'ANSI'` hingegen ist die Isolierungsstufe nicht betroffen.

Siehe auch Abschnitt 5.2.1, „Befehlsoptionen für mysqld“, und Abschnitt 1.9.2, „Auswahl der SQL-Modi“.

### 1.9.4. MySQL-Erweiterungen zu ANSI SQL92

MySQL Server unterstützt einige Erweiterungen, die Sie in anderen Datenbankmanagementsystemen wahrscheinlich nicht finden werden. Beachten Sie in jedem Fall, dass, wenn Sie diese Erweiterungen verwenden, Ihr Code nicht auf andere SQL-Server portierbar ist. In manchen Fällen können Sie Code schreiben, der MySQL-Erweiterungen enthält, aber trotzdem portierbar ist; Sie müssen dann Kommentare in der folgenden Form verwenden:

    /*! MySQL-specific code */

In diesem Fall verarbeitet MySQL Server den Code innerhalb des Kommentars wie normale SQL-Anweisungen; andere SQL-Server hingegen ignorieren die Erweiterungen. So erkennt MySQL Server beispielsweise anders als andere Server das Schlüsselwort `STRAIGHT_JOIN` in der folgenden Anweisung:

    SELECT /*! STRAIGHT_JOIN */ col1 FROM table1,table2 WHERE ...

Wenn Sie nach dem Zeichen ‘`!`’ die Versionsnummer angeben, wird die Syntax nur ausgeführt, wenn die betreffende oder eine neuere MySQL-Version verwendet wird. Das Schlüsselwort `TEMPORARY` im folgenden Kommentar wird nur von Servern ausgeführt, auf denen MySQL 3.23.02 oder höher läuft:

    CREATE /*!32302 TEMPORARY */ TABLE t (a INT);

Die folgenden Beschreibungen listen MySQL-Erweiterungen nach Kategorie sortiert auf.

- Organisation der Daten auf der Festplatte

  MySQL Server ordnet jede Datenbank einem Unterverzeichnis des MySQL-Datenverzeichnisses zu. Tabellen innerhalb einer Datenbank entsprechen den Dateinamen im Datenbankverzeichnis. Dies hat einige Auswirkungen:

  - Die Groß-/Kleinschreibung bei Datenbank- und Tabellennamen in MySQL Server wird bei solchen Betriebssystemen unterschieden, die auch eine Unterscheidung der Groß-/Kleinschreibung bei den Dateinamen vornehmen (also etwa die Mehrzahl der Unix-Systeme). Siehe auch Abschnitt 9.2.2, „Groß-/Kleinschreibung in Namen“.

  - Sie können Standardsystembefehle zum Sichern, Umbenennen, Verschieben, Löschen und Kopieren von Tabellen verwenden, die von der `MyISAM`-Speicher-Engine verwaltet werden. So können Sie eine `MyISAM`-Tabelle etwa umbenennen, indem Sie die Namen der `.MYD`-, `.MYI`- und `.frm`-Dateien ändern, denen die Tabelle entspricht. (Nichtsdestoweniger ist die Verwendung von `RENAME TABLE` bzw. `ALTER TABLE ... RENAME` und die Umbenennung der Dateien durch den Server vorzuziehen.)

  Datenbank- und Tabellennamen dürfen keine Pfadtrennzeichen (‘`/`’, ‘`\`’) enthalten.

- Allgemeine Sprachsyntax

  - Standardmäßig dürfen Strings von den Zeichen ‘`"`’ oder ‘`'`’ umschlossen sein und nicht nur von ‘`'`’. (Wenn der SQL-Modus `ANSI_QUOTES` aktiviert ist, dürfen die Strings nur vom Zeichen ‘`'`’ umfasst sein; Strings, die von ‘`"`’ umfasst sind, interpretiert der Server als Bezeichner.)

  - Verwendung von ‘`\`’ als Escape-Zeichen in Strings.

  - In SQL-Anweisungen können Sie mithilfe der Syntax `db_name.tbl_name` auf Tabellen aus anderen Datenbanken zugreifen. Einige SQL-Server bieten die gleiche Funktionalität, nennen dies aber `User-Space`. MySQL Server unterstützt Tabellenräume, wie sie etwa in der folgenden Anweisung verwendet werden, nicht: `CREATE TABLE ralph.my_table...IN my_tablespace`.

- SQL-Anweisungssyntax

  - Die Anweisungen `ANALYZE TABLE`, `CHECK TABLE`, `OPTIMIZE TABLE` und `REPAIR TABLE`.

  - Die Anweisungen `CREATE DATABASE`, `DROP DATABASE` und `ALTER DATABASE`. Siehe auch Abschnitt 13.1.3, „`CREATE DATABASE`“, Abschnitt 13.1.6, „`DROP DATABASE`“, und Abschnitt 13.1.1, „`ALTER DATABASE`“.

  - Die Anweisung `DO`.

  - `EXPLAIN SELECT` ruft eine Beschreibung dazu auf, wie Tabellen durch die Abfrageoptimierung verarbeitet werden.

  - Die Anweisungen `FLUSH` und `RESET`.

  - Die Anweisung `SET`. Siehe auch Abschnitt 13.5.3, „`SET`“.

  - Die Anweisung `SHOW`. Siehe auch Abschnitt 13.5.4, „`SHOW`“. Ab MySQL 5.0 lassen sich die Angaben, die von vielen der MySQL-spezifischen `SHOW`-Anweisungen erzeugt werden, auf standardkonformere Weise durch Verwendung von `SELECT` zur Abfrage von `INFORMATION_SCHEMA` erhalten. Siehe auch Kapitel 22, Die Datenbank `INFORMATION_SCHEMA`.

  - Verwenden von `LOAD DATA INFILE`. In vielen Fällen ist die Syntax kompatibel mit Oracles `LOAD DATA INFILE`. Siehe auch Abschnitt 13.2.5, „`LOAD DATA INFILE`“.

  - Verwendung von `RENAME TABLE`. Siehe auch Abschnitt 13.1.9, „`RENAME TABLE`“.

  - Verwendung von `REPLACE` anstelle der Kombination `DELETE` und `INSERT`. Siehe auch Abschnitt 13.2.6, „`REPLACE`“.

  - Verwendung von `CHANGE `col_name``, `DROP `col_name`` oder `DROP INDEX`, `IGNORE` oder `RENAME` in `ALTER TABLE`-Anweisungen. Verwendung mehrerer `ADD`-, `ALTER`-, `DROP`- oder `CHANGE`-Klauseln in einer `ALTER TABLE`-Anweisung. Siehe auch Abschnitt 13.1.2, „`ALTER TABLE`“.

  - Verwendung von Indexnamen, Indizes für das Präfix einer Spalte und Verwendung von `INDEX` oder `KEY` in `CREATE TABLE`-Anweisungen. Siehe auch Abschnitt 13.1.5, „`CREATE TABLE`“.

  - Verwendung von `TEMPORARY` oder `IF NOT EXISTS` mit `CREATE TABLE`.

  - Verwendung von `IF EXISTS` mit `DROP TABLE` und `DROP DATABASE`.

  - Die Möglichkeit, mehrere Tabellen mit einer einzigen `DROP TABLE`-Anweisung zu löschen.

  - Die Klauseln `ORDER BY` und `LIMIT` der Anweisungen `UPDATE` und `DELETE`.

  - Die Syntax `INSERT INTO ... SET `col_name` = ...`.

  - Die Klausel `DELAYED` der Anweisungen `INSERT` und `REPLACE`.

  - Die Klausel `LOW_PRIORITY` der Anweisungen `INSERT`, `REPLACE`, `DELETE` und `UPDATE`.

  - Verwendung von `INTO OUTFILE` oder `INTO DUMPFILE` in `SELECT`-Anweisungen. Siehe auch Abschnitt 13.2.7, „`SELECT`“.

  - Optionen wie `STRAIGHT_JOIN` oder `SQL_SMALL_RESULT` in `SELECT`-Anweisungen.

  - In der Klausel `GROUP BY` müssen Sie nicht alle gewählten Spalten benennen. Hierdurch erhalten Sie eine bessere Leistung bei einigen sehr speziellen, aber trotzdem recht häufig auftretenden Abfragen. Siehe auch Abschnitt 12.11, „Funktionen und Modifizierer für die Verwendung in `GROUP BY`-Klauseln“.

  - Sie können `ASC` und `DESC` mit `GROUP BY` und nicht nur mit `ORDER BY` festlegen.

  - Die Möglichkeit, Variablen in einer Anweisung mit dem Zuweisungsoperator `:=` festzulegen:

        mysql> SELECT @a:=SUM(total),@b=COUNT(*),@a/@b AS avg
            -> FROM test_table;
        mysql> SELECT @t1:=(@t2:=1)+@t3:=4,@t1,@t2,@t3;

- Datentypen

  - Die Datentypen `MEDIUMINT`, `SET` und `ENUM` sowie die verschiedenen `BLOB`- und `TEXT`-Datentypen.

  - Die Datentypattribute `AUTO_INCREMENT`, `BINARY`, `NULL`, `UNSIGNED` und `ZEROFILL`.

- Funktionen und Operatoren

  - Um Benutzern anderer SQL-Umgebungen den Umstieg auf MySQL zu erleichtern, unterstützt MySQL Server Aliase für eine Reihe von Funktionen. So unterstützen etwa alle String-Funktionen sowohl die Standard-SQL- als auch die ODBC-Syntax.

  - MySQL Server fasst die Operatoren `||` und `&&` als logisches ODER bzw. UND auf, wie man es von der Programmiersprache C her kennt. In MySQL Server sind `||` und `OR` Synonyme; Gleiches gilt für `&&` und `AND`. Aufgrund dieser praktischen syntaktischen Eigenschaften unterstützt MySQL Server den Standard-SQL-Operator `||` für die String-Verkettung nicht; verwenden Sie stattdessen `CONCAT()`. Da `CONCAT()` eine beliebige Anzahl von Argumenten entgegennimmt, ist es ganz einfach, die Verwendung des Operators `||` in MySQL Server nachzubilden.

  - Verwendung von `COUNT(DISTINCT `value_list`)`, wobei `value_list` mehr als ein Element aufweist.

  - Standardmäßig wird bei String-Vergleichen die Groß-/Kleinschreibung unterschieden, wobei die Sortierreihenfolge vom aktuellen Zeichensatz bestimmt wird; dieser ist vorgabeseitig `latin1` (cp1252 West European). Wenn Sie das nicht wollen, sollten Sie Ihre Spalten mit dem Attribut `BINARY` deklarieren oder `BINARY` zur Umwandlung verwenden, was Vergleiche auf der Basis des zugrunde liegenden Zeichensatzes (statt der lexikalischen Anordnung) ermöglicht.

  - Der Operator `%` ist ein Synonym zu `MOD()`. Infolgedessen ist ``N` % `M`` gleichbedeutend mit `MOD(`N`,`M`)`. `%` wird für C-Programmierer und aus Gründen der Kompatibilität mit PostgreSQL unterstützt.

  - Die Operatoren `=`, `<>`, `<=`,`<`, `>=`,`>`, `<<`, `>>`, `<=>`, `AND`, `OR` und `LIKE` können in Ausdrücken in der Ausgabespaltenliste (links von `FROM`) in `SELECT`-Anweisungen verwendet werden. Ein Beispiel:

        mysql> SELECT col1=1 AND col2=2 FROM my_table;

  - Die Funktion `LAST_INSERT_ID()` gibt den aktuellen `AUTO_INCREMENT`-Wert zurück. Siehe auch Abschnitt 12.10.3, „Informationsfunktionen“.

  - `LIKE` ist für numerische Werte zulässig.

  - Die Operatoren `REGEXP` and `NOT REGEXP` für erweiterte reguläre Ausdrücke.

  - `CONCAT()` oder `CHAR()` mit einem oder mehr als zwei Argumenten. (In MySQL Server können diese Funktionen eine variable Anzahl von Argumenten entgegennehmen.)

  - Die Funktionen `BIT_COUNT()`, `CASE`, `ELT()`, `FROM_DAYS()`, `FORMAT()`, `IF()`, `PASSWORD()`, `ENCRYPT()`, `MD5()`, `ENCODE()`, `DECODE()`, `PERIOD_ADD()`, `PERIOD_DIFF()`, `TO_DAYS()` und `WEEKDAY()`.

  - Verwendung von `TRIM()` zum Zurechtschneiden von Teil-Strings. Standard-SQL unterstützt nur die Entfernung einzelner Zeichen.

  - Die `GROUP BY`-Funktionen `STD()`, `BIT_OR()`, `BIT_AND()`, `BIT_XOR()` und `GROUP_CONCAT()`. Siehe auch Abschnitt 12.11, „Funktionen und Modifizierer für die Verwendung in `GROUP BY`-Klauseln“.

Eine priorisierte Liste mit Angaben dazu, wann MySQL Server durch neue Erweiterungen ergänzt wird, finden Sie im MySQL-Entwicklungsfahrplan unter http://dev.mysql.com/doc/mysql/en/roadmap.html.

### 1.9.5. MySQL: Unterschiede im Vergleich zu ANSI SQL92

Wir versuchen, MySQL Server möglichst nah an die ANSI-SQL- und ODBC-SQL-Standards zu halten. Allerdings führt MySQL Server manche Operationen in bestimmten Fällen anders aus:

- Bei `VARCHAR`-Spalten werden führende Leerzeichen beim Speichern des Werts entfernt (dies wurde in MySQL 5.0.3 behoben). Siehe auch Abschnitt A.8, „Bekannte Fehler und konzeptionelle Unzulänglichkeiten in MySQL“.

- In manchen Fällen werden `CHAR`-Spalten stillschweigend in `VARCHAR`-Spalten konvertiert, wenn Sie eine Tabelle definieren oder ihre Struktur ändern (dies wurde in MySQL 5.0.3 behoben).

- Es gibt eine Reihe von Unterschieden zwischen den Berechtigungssystemen von MySQL und Standard-SQL. Beispielsweise werden in MySQL Berechtigungen für eine Tabelle nicht automatisch widerrufen, wenn Sie die Tabelle löschen. Um die Berechtigungen für die Tabelle zu widerrufen, müssen Sie explizit eine `REVOKE`-Anweisung absetzen. Weitere Informationen finden Sie unter Abschnitt 13.5.1.5, „`REVOKE`“.

- Die Funktion `CAST()` unterstützt die Umwandlung in `REAL` oder `BIGINT` nicht. Siehe auch Abschnitt 12.8, „Cast-Funktionen und Operatoren“.

- Standard-SQL setzt voraus, dass eine `HAVING`-Klausel in einer `SELECT`-Anweisung auf Spalten in der `GROUP BY`-Klausel verweist. Dies ist erst ab MySQL 5.0.2 möglich.

#### 1.9.5.1. Unterstützung für Unterabfragen

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

#### 1.9.5.2. `SELECT INTO TABLE`

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

#### 1.9.5.3. Transaktionen

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?

- Wenn Ihre Anwendungen so geschrieben sind, dass sie in kritischen Situationen von der Fähigkeit zum Aufruf von `ROLLBACK` anstelle von `COMMIT` abhängen, dann sind Transaktionen praktischer. Mit Transaktionen lässt sich auch sicherstellen, dass nicht abgeschlossene Updates oder beschädigende Aktionen nicht in die Datenbank übertragen werden; der Server hat die Möglichkeit, einen automatischen Rollback durchzuführen, und Ihre Datenbank ist gerettet.

  Wenn Sie nichttransaktionale Tabellen verwenden, gestattet Ihnen MySQL Server in fast allen Fällen die Lösung potenzieller Probleme durch Integrierung einfacher Prüfungen vor Updates und Ausführung simpler Skripten, die die Datenbank auf Inkonsistenzen untersuchen und diese ggf. automatisch reparieren bzw. Warnmeldungen anzeigen. Beachten Sie, dass Sie Tabellen normalerweise mithilfe der MySQL-Logdatei oder einer zusätzlichen Logdatei reparieren, ohne dass die Datenintegrität hiervon beeinträchtigt würde.

- In der Mehrzahl der Fälle lassen sich kritische transaktionale Updates so umformulieren, dass sie atomar sind. Allgemein gesprochen lassen sich alle Integritätsprobleme, die sich mit Transaktionen lösen lassen, mit `LOCK TABLES` oder atomaren Updates beseitigen. Hierdurch ist sichergestellt, dass ein Vorgang serverseitig nicht abgebrochen wird – ein Problem, welches bei transaktionalen Datenbanksystemen häufig auftritt.

- Um unabhängig davon, ob Sie transaktionale Tabellen verwenden, mit MySQL Server sicher arbeiten zu können, müssen Sie nur über Backups verfügen und die binäre Protokollierung aktiviert haben. Sind diese Voraussetzungen erfüllt, dann können Sie wie bei anderen transaktionalen Datenbanksystemen einen fehlerlosen Zustand jederzeit wiederherstellen. Sicherungskopien sollten immer vorhanden sein – egal, welches Datenbanksystem Sie verwenden.

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:

- Schleifen, die Transaktionen erfordern, lassen sich normalerweise mithilfe von `LOCK TABLES` kopieren. Sie benötigen keine Cursor, um Datensätze direkt zu aktualisieren.

- Um die Verwendung von `ROLLBACK` zu umgehen, können Sie die folgende Strategie verwenden:

  1. Sperren Sie alle Tabellen, auf die Sie zugreifen wollen, mit `LOCK TABLES`.

  2. Prüfen Sie die Bedingungen, die wahr sein müssen, bevor Sie das Update durchführen.

  3. Sind alle Bedingungen erfüllt, dann führen Sie das Update durch.

  4. Heben Sie die Sperrungen Ihrer Tabellen mit `UNLOCK TABLES` auf.

  Wenn auch nicht immer, so funktioniert dies in der Regel doch wesentlich schneller als die Verwendung von Transaktionen mit möglichen Rollbacks. Die einzige Situation, die mit dieser Lösung nicht bereinigt werden kann, liegt vor, wenn jemand die Threads während eines Updates beendet. In diesem Fall werden alle Sperren aufgehoben, aber unter Umständen wurden manche Updates nicht ausgeführt.

- Sie können auch Funktionen zur Aktualisierung von Datensätzen in einer einzigen Operation verwenden. Mithilfe der folgenden Methode erhalten Sie eine sehr effiziente Anwendung:

  - Ändern Sie die Spalten relativ zum aktuellen Wert.

  - Aktualisieren Sie nur solche Spalten, die tatsächlich geändert wurden.

  Wenn wir beispielsweise Kundendaten aktualisieren, dann aktualisieren wir nur diejenigen Kundendaten, die sich auch geändert haben, und überprüfen nachfolgend lediglich, ob sich geänderte Daten oder Daten, die von den geänderten Daten abhängen, verglichen mit dem ursprünglichen Datensatz geändert haben. Die Überprüfung auf geänderte Daten erfolgt mit der `WHERE`-Klausel in der `UPDATE`-Anweisung. Wurde der Datensatz nicht aktualisiert, dann erhält der Client folgende Mitteilung: „Some of the data you have changed has been changed by another user.“ („Einige Daten, die Sie geändert haben, wurden von einem anderen Benutzer geändert.“) Dann werden der alte und der neue Datensatz in einem Fenster zu Vergleichszwecken angezeigt, damit der Benutzer entscheiden kann, welche Version des Kundendatensatzes zukünftig verwendet werden soll.

  Auf diese Weise erhalten wir etwas, dass der Sperrung einer Spalte ähnelt, tatsächlich aber noch besser ist, da nur einige Spalten mithilfe von Werten aktualisiert werden, die relativ zu den aktuellen Werten sind. Dies wiederum bedeutet, dass eine typische `UPDATE`-Anweisung etwa so aussieht:

      UPDATE tablename SET pay_back=pay_back+125;

      UPDATE customer
        SET
          customer_date='current_date',
          address='new address',
          phone='new phone',
          money_owed_to_us=money_owed_to_us-125
        WHERE
          customer_id=id AND address='old address' AND phone='old phone';

  Dies ist sehr effizient und funktioniert auch dann, wenn ein anderer Client die Werte in den Spalten `pay_back` oder `money_owed_to_us` geändert hat.

- In vielen Fällen wünschten sich Benutzer `LOCK TABLES` oder `ROLLBACK`, um eindeutige Bezeichner verwalten zu können. Dies lässt sich jedoch weitaus effizienter ohne Sperrung oder Rollback realisieren, indem man eine `AUTO_INCREMENT`-Spalte und entweder die SQL-Funktion `LAST_INSERT_ID()` oder die C-API-Funktion `mysql_insert_id()` verwendet. Siehe auch Abschnitt 12.10.3, „Informationsfunktionen“, und Abschnitt 24.2.3.36, „`mysql_insert_id()`“.

  Sie können die Notwendigkeit, eine Sperrung auf Datensatzebene vorzunehmen, im Allgemeinen durch entsprechende Programmierung umgehen. In manchen Situationen jedoch ist diese Sperrung erforderlich, und `InnoDB`-Tabellen unterstützen sie auch. Andernfalls können Sie bei `MyISAM`-Tabellen eine Flag-Spalte verwenden und etwa Folgendes machen:

      UPDATE tbl_name SET row_flag=1 WHERE id=ID;

  MySQL gibt `1` als Anzahl der betroffenen Datensätze zurück, wenn der Datensatz gefunden wurde und `row_flag` im ursprünglichen Datensatz nicht `1` war. Sie können sich das so vorstellen, als ob MySQL Server die obige Anweisung wie folgt geändert hätte:

      UPDATE tbl_name SET row_flag=1 WHERE id=ID AND row_flag <> 1;

#### 1.9.5.4. Gespeicherte Prozeduren und Trigger

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.

#### 1.9.5.5. Fremdschlüssel

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:

- Setzt man einen guten Entwurf der Beziehungen voraus, dann erschweren Fremdschlüsselbeschränkungen es dem Programmierer, Inkonsistenzen in die Datenbank einzubringen.

- Die zentralisierte Überprüfung der Beschränkungen durch den Datenbankserver macht eine Durchführung dieser Überprüfungen auf Anwendungsseite unnötig. Auf diese Weise wird die Möglichkeit beseitigt, dass verschiedene Anwendungen unter Umständen nicht alle Beschränkungen auf gleiche Weise überprüfen.

- Dank der Verwendung kaskadierender Updates und Löschungen kann der Anwendungscode vereinfacht werden.

- Korrekt entworfene Fremdschlüsselregeln unterstützen Sie bei der Dokumentation von Beziehungen zwischen Tabellen.

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:

- Fehlt die serverseitige Überprüfung der Fremdschlüsselbeziehung, dann muss die Anwendung sich selbst um die Aspekte der Beziehung kümmern. Sie muss beispielsweise dafür sorgen, dass Datensätze in der korrekten Reihenfolge in Tabellen eingetragen werden und dass keine verwaisten Unterdatensätze erstellt werden. Ferner muss sie in der Lage sein, Fehler, die bei Einfügevorgängen für mehrere Datensätze auftreten, beheben zu können.

- Wenn `ON DELETE` die einzige referenzielle Integritätsfunktion ist, die eine Anwendung benötigt, dann können Sie ab MySQL Server 4.0 einen ähnlichen Effekt erzielen, indem Sie `DELETE`-Anweisungen über mehrere Tabellen verwenden; so können Sie Datensätze aus mehreren Tabellen mit nur einer Anweisung löschen. Siehe auch Abschnitt 13.2.1, „`DELETE`“.

- Ein Workaround für das Fehlen von `ON DELETE` besteht darin, die passenden `DELETE`-Anweisungen in Ihrer Anwendung hinzuzufügen, wenn Sie Datensätze aus einer Tabelle löschen, die einen Fremdschlüssel beinhaltet. In der Praxis kann dies häufig ebenso schnell sein wie die Verwendung von Fremdschlüsseln – und ist zudem besser portierbar.

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

- Die Unterstützung von Fremdschlüsseln beseitigt eine Reihe von Schwierigkeiten bei der referenziellen Integrität, aber es ist nach wie vor erforderlich, Schlüsselbeziehungen mit Sorgfalt zu erstellen, damit zirkulare Regeln oder falsche Kombinationen kaskadierender Löschungen ausgeschlossen werden.

- Es kommt häufig vor, dass ein Datenbankadministrator eine Beziehungstopologie erstellt, die die Wiederherstellung einzelner Tabellen aus einem Backup erschwert. (MySQL schwächt dieses Problem ab, indem es Ihnen die temporäre Deaktivierung von Fremdschlüsselüberprüfungen gestattet, wenn Sie eine Tabelle neu laden, die von anderen Tabellen abhängt. Siehe auch Abschnitt 14.2.6.4, „Fremdschlüssel-Beschränkungen“. Ab MySQL 4.1.1 erzeugt mysqldump Speicherauszugsdateien, die diesen Vorteil automatisch nutzen, wenn sie neu geladen werden.)

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.

#### 1.9.5.6. Sichten (Views)

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

#### 1.9.5.7. '`--`' als Beginn eines Kommentars

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

### 1.9.6. Wie MySQL mit Constraints umgeht

MySQL erlaubt Ihnen die Verwendung sowohl von transaktionalen Tabellen, die Rollbacks unterstützen, als auch von nichttransaktionalen Tabellen ohne Rollback. Aus diesem Grund unterscheidet sich der Umgang mit Constraints in MySQL ein wenig von dem in anderen Datenbanksystemen. Wir müssen den Fall beschreiben, der vorliegt, wenn Sie eine große Menge von Datensätzen in einer nichttransaktionalen Tabelle, bei der im Fehlerfall kein Rollback möglich ist, eingefügt oder aktualisiert haben.

Die Grundphilosophie besteht darin, dass MySQL Server versucht, einen Fehler für alle Probleme zu generieren, die während der Verarbeitung einer auszuführenden Anweisung erkannt wurden; gleichzeitig wird versucht, den fehlerfreien Status in Bezug auf alle Fehler wiederherzustellen, die während der Ausführung der Anweisung auftreten. Das lässt sich in den meisten, jedoch nicht in allen Fällen realisieren.

Wenn ein Fehler auftritt, hat MySQL zwei Optionen: Es kann die Ausführung der Anweisung abbrechen oder das Problem bestmöglich beheben und dann fortfahren. Standardmäßig verfolgt der Server die zweite Option. Dies bedeutet beispielsweise, dass der Server unzulässige Werte automatisch auf die nächstgelegenen zulässigen Werte verschiebt.

Es gibt mehrere SQL-Modusoptionen, die eine bessere Kontrolle der Handhabung unzulässiger Datenwerte und der Frage gestatten, ob die Ausführung einer Anweisung im Fehlerfall fortgeführt oder abgebrochen werden soll. Mithilfe dieser Optionen können Sie MySQL Server so konfigurieren, dass es auf eine traditionellere Weise agiert, die anderen Datenbanksystemen ähnelt, bei denen unzulässige Eingaben nicht angenommen werden. Der SQL-Modus kann global beim Serverstart eingestellt werden und betrifft dann alle Clients. Einzelne Clients können den SQL-Modus während der Laufzeit einstellen; auf diese Weise kann jeder Client das Verhalten auswählen, welches für seine speziellen Anforderungen am geeignetsten ist. Siehe auch Abschnitt 5.2.5, „Der SQL-Modus des Servers“.

Die folgenden Abschnitte beschreiben, wie MySQL Server verschiedene Arten von Constraints handhabt.

#### 1.9.6.1. `PRIMARY KEY`- und `UNIQUE`-Index-Constraints

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

#### 1.9.6.2. Constraints auf ungültigen Daten

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:

- Wenn Sie versuchen, einen Wert außerhalb des zulässigen Bereichs in einer numerischen Spalte zu speichern, dann speichert MySQL Server stattdessen null, den kleinstmöglichen oder den größtmöglichen Wert – abhängig davon, welcher gültige Wert am nächsten liegt.

- Bei Strings speichert MySQL entweder den Leer-String oder den Teil des Strings, der sich in der Spalte speichern lässt.

- Wenn Sie in einer numerischen Spalte einen String speichern wollen, der nicht mit einer Zahl beginnt, dann speichert MySQL Server 0.

- Mit ungültigen Werten für `ENUM`- und `SET`-Spalten wird wie in Abschnitt 1.9.6.3, „`ENUM`- und `SET`-Constraints“, beschrieben verfahren.

- MySQL gestattet die Speicherung bestimmter unzulässiger Werte in `DATE`- und `DATETIME`-Spalten (z. B. `'2000-02-31'` oder `'2000-02-00'`). Der Grundgedanke dahinter ist der, dass es nicht Aufgabe des SQL-Servers sein kann, Datumsangaben auszuwerten. Wenn MySQL einen Datumswert speichern und den exakt gleichen Wert wieder abrufen kann, dann speichert MySQL ihn auch wie eingegeben. Ist das Datum jedoch völlig falsch (d. h., es kann nicht vom Server gespeichert werden), dann wird stattdessen der spezielle „Nulldatumswert“ `'0000-00-00'` in der Spalte abgelegt.

- Wenn Sie `NULL` in einer Spalte speichern wollen, die keine `NULL`-Werte akzeptiert, dann erscheint bei `INSERT`-Anweisungen für einzelne Datensätze ein Fehler. Bei `INSERT`-Anweisungen für mehrere Datensätze oder `INSERT INTO ... SELECT`-Anweisungen hingegen speichert MySQL Server den impliziten Vorgabewert für den Datentyp der Spalte. In der Regel ist dies `0` bei numerischen Typen, der Leer-String (`''`) bei String-Typen und der „Nullwert“ für Datums- und Uhrzeittypen. Implizite Vorgabewerte werden in Abschnitt 11.1.4, „Vorgabewerte von Datentypen“, behandelt.

- Wenn eine `INSERT`-Anweisung keinen Wert für eine Spalte angibt, fügt MySQL den Vorgabewert ein, sofern die Spaltendefinition eine explizite `DEFAULT`-Klausel enthält. Ist eine solche `DEFAULT`-Klausel nicht in der Definition enthalten, dann fügt MySQL den impliziten Vorgabewert für den Datentyp der Spalte ein.

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:

- Bei transaktionalen Speicher-Engines wird bei Auftreten unzulässiger Werte in einer Anweisung die Ausführung dieser Anweisung abgebrochen und ein Rollback durchgeführt.

- Bei nichttransaktionalen Speicher-Engines wird die Anweisung abgebrochen, wenn der Fehler beim ersten einzufügenden bzw. zu aktualisierenden Datensatz auftritt. (Tritt der Fehler beim ersten Datensatz auf, dann kann die Anweisung wie bei transaktionalen Tabellen abgebrochen werden, ohne dass Änderungen in der Tabelle erfolgt wären.) Fehler in nachfolgenden Datensätzen brechen die Anweisung nicht ab, denn in der Tabelle wurden bereits Änderungen vorgenommen. Stattdessen werden unzulässige Datensätze korrigiert und Warnungen (anstelle von Fehlern) erzeugt. Mit anderen Worten: Bei `STRICT_TRANS_TABLES` hat ein falscher Wert zur Folge, dass MySQL einen Rollback aller bereits durchgeführten Aktualisierungen vornimmt, sofern dies ohne Änderungen in der Tabelle möglich ist. Wurde die Tabelle jedoch bereits geändert, dann führen weitere Fehler zu Korrekturen und Warnungen.

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.

#### 1.9.6.3. `ENUM`- und `SET`-Constraints

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

- `ENUM`-Spalten haben immer einen Vorgabewert. Wenn Sie keinen Vorgabewert angeben, dann ist er `NULL` für Spalten, die `NULL` unterstützen, andernfalls der erste Aufzählungswert in der Spaltendefinition.

- Fügen Sie einen falschen Wert in eine `ENUM`-Spalte ein oder erzwingen einen Wert in einer `ENUM`-Spalte mithilfe von `IGNORE`, dann wird dieser auf den reservierten Aufzählungswert `0` gesetzt, der als Leer-String im String-Kontext angezeigt wird.

- Wenn Sie einen falschen Wert in eine `SET`-Spalte einfügen, wird dieser falsche Wert ignoriert. Kann die Spalte beispielsweise die Werte `'a'`, `'b'` und `'c'` enthalten, dann würde der Versuch, `'a,x,b,y'` zuzuweisen, den Wert `'a,b'` zur Folge haben.

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:

- Ein `ENUM`-Wert muss zu der Wertemenge gehören, die in der Spaltendefinition aufgelistet ist, oder ein internes numerisches Äquivalent eines Werts in der Wertemenge sein. Der Wert darf nicht der Fehlerwert (also 0 oder der Leer-String) sein. Bei einer Spalte, die als `ENUM('a','b','c')` definiert ist, sind Werte wie etwa `''`, `'d'` oder `'ax'` unzulässig und werden abgewiesen.

- Ein `SET`-Wert muss der Leer-String oder ein Wert sein, der nur aus den in der Spaltendefinition aufgeführten Werten besteht, die durch Kommata getrennt sind. Bei einer Spalte, die als `SET('a','b','c')` definiert ist, sind Werte wie etwa `'d'` oder `'a,b,c,d'` unzulässig und werden abgewiesen.

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'`.

Dies ist eine Übersetzung des MySQL-Referenzhandbuchs, das sich auf dev.mysql.com befindet. Das ursprüngliche Referenzhandbuch ist auf Englisch, und diese Übersetzung ist nicht notwendigerweise so aktuell wie die englische Ausgabe. Das vorliegende deutschsprachige Handbuch behandelt MySQL bis zur Version 5.1.

Zurück |  | Weiter
Vorwort | Zum Anfang | Kapitel 2. Installation von MySQL