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.

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

Interna und Portabilität:

Datentypen:

Anweisungen und Funktionen:

Sicherheit:

Skalierbarkeit und Grenzen:

Konnektivität:

Lokalisierung:

Clients und Werkzeuge:

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:

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 (256⁷ – 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.

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:

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

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.

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.

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.

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:

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

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

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.

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

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:

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.

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:

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

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

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.

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

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

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.

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.

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:

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

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

UPDATE account SET credit=credit-!payment!

UPDATE account SET credit=credit--1

UPDATE account SET credit=credit

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

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

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

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

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.

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