Kapitel 9. Sprachstruktur
Zurück |  | Weiter

## Kapitel 9. Sprachstruktur

Dieses Kapitel erläutert die Notationsregeln für die folgenden Elemente von SQL-Anweisungen bei der Verwendung von MySQL:

- literale Werte wie etwa Strings und Zahlen

- Bezeichner wie Datenbank-, Tabellen- und Spaltennamen

- benutzerdefinierte und Systemvariablen

- Kommentare

- reservierte Wörter

## 9.1. Literale: wie Strings und Zahlen geschrieben werden

In diesem Abschnitt wird erläutert, wie literale Werte in MySQL geschrieben werden. Hierzu gehören Strings, Zahlen, Hexadezimalwerte, boolesche Werte und `NULL`. Ferner behandeln wir hier die verschiedenen Nuancen und Fallstricke, auf die Sie beim Umgang mit diesen Grundtypen in MySQL treffen können.

### 9.1.1. Strings

Ein String ist eine Abfolge von Bytes oder Zeichen, die in einfache (‘`'`’) oder doppelte Anführungszeichen (‘`"`’) gesetzt sind. Ein paar Beispiele:

    'a string'
    "another string"

Wenn der SQL-Modus `ANSI_QUOTES` aktiviert ist, dürfen String-Literale nur in einfache Anführungszeichen gesetzt werden. Ein in doppelten Anführungszeichen stehender String wird als Bezeichner interpretiert.

Ein binärer String ist ein String, für den kein Zeichensatz und keine Sortierung definiert sind. Ein nichtbinärer String hingegen ist ein String, für den Zeichensatz und Sortierung definiert sind. Bei beiden String-Typen basieren Vergleiche auf den numerischen Werten der String-Einheit. Bei binären Strings ist dies das Byte, bei nichtbinären Strings das einzelne Zeichen (wobei zu beachten ist, dass manche Zeichensätze Zeichen enthalten, die aus mehreren Bytes bestehen).

String-Literale weisen unter Umständen eine optionale Zeichensatzeinführung und eine `COLLATE`-Klausel auf:

    [_charset_name]'string' [COLLATE collation_name]

Ein paar Beispiele:

    SELECT _latin1'string';
    SELECT _latin1'string' COLLATE latin1_danish_ci;

Weitere Informationen zu diesen Syntaxtypen für Strings finden Sie in Abschnitt 10.3.5, „Zeichensatz und Sortierfolge literaler Strings“.

Innerhalb eines Strings haben bestimmte Sequenzen jeweils eine spezielle Bedeutung. Jede dieser Sequenzen beginnt mit einem Backslash (‘`\`’). Dieser wird häufig als Escape-Zeichen bezeichnet. MySQL erkennt die folgenden Escape-Sequenzen:

`\0` | ASCII-konformes 0-Zeichen (`NUL`).
`\'` | Ein einfaches Anführungszeichen (‘`'`’).
`\"` | Ein doppeltes Anführungszeichen (‘`"`’).
`\b` | Ein Rückschrittzeichen.
`\n` | Ein Zeilenwechsel- oder Zeilenvorschubzeichen.
`\r` | Ein Absatzschaltungszeichen.
`\t` | Ein Tabulatorzeichen.
`\Z` | ASCII 26 (Strg+Z). Siehe Anmerkung nach dieser Tabelle.
`\\` | Ein Backslash-Zeichen (‘`\`’).
`\%` | Ein ‘`%`’-Zeichen. Siehe Anmerkung nach dieser Tabelle.
`\_` | Ein ‘`_`’-Zeichen. Siehe Anmerkung nach dieser Tabelle.

Diese Sequenzen unterscheiden die Groß-/Kleinschreibung. So wird etwa ‘`\b`’ als Rückschritt, ‘`\B`’ hingegen als ‘`B`’ interpretiert.

Das ASCII-Zeichen 26 kann als ‘`\Z`’ kodiert werden; hierdurch umgehen Sie Probleme mit der Tatsache, dass dieses Zeichen unter Windows als Dateiende interpretiert wird. Das ASCII-Zeichen 26 verursacht in einer Datei Probleme, wenn Sie `mysql `db_name`< `file_name`` verwenden.

Die Sequenzen ‘`\%`’ und ‘`\_`’ erlauben die Suche nach literalen Instanzen von ‘`%`’ und ‘`_`’ in Mustervergleichskontexten, in denen sie andernfalls als Jokerzeichen interpretiert würden. Details finden Sie in der Beschreibung zum Operator `LIKE` in Abschnitt 12.3.1, „String-Vergleichsfunktionen“. Wenn Sie ‘`\%`’ oder ‘`\_`’ in Kontexten ohne Mustervergleich verwenden, werden diese als Strings ‘`\%`’ und ‘`\_`’ und nicht als ‘`%`’ und ‘`_`’ ausgewertet.

Bei allen anderen Escape-Sequenzen wird der Backslash ignoriert. Das bedeutet, dass das gekennzeichnete Zeichen als nicht gekennzeichnetes interpretiert wird. So ist etwa ‘`\x`’ identisch mit ‘`x`’.

Es gibt mehrere Möglichkeiten, Anführungszeichen in einen String zu setzen:

- Ein ‘`'`’ in einem String, der in ‘`'`’ gesetzt ist, kann als ‘`''`’ geschrieben werden.

- Ein ‘`"`’ in einem String, der in ‘`"`’ gesetzt ist, kann als ‘`""`’ geschrieben werden.

- Sie stellen dem Anführungszeichen ein Escape-Zeichen (‘`\`’) voran.

- Ein ‘`'`’ in einem String, der in ‘`"`’ gesetzt ist, erfordert keine spezielle Behandlung und muss weder verdoppelt noch mit einem Escape-Zeichen versehen werden. Ebenso erfordert ein ‘`"`’ in einem String, der in ‘`'`’ gesetzt ist, keine Sonderbehandlung.

Die folgenden `SELECT`-Anweisungen veranschaulichen die Verwendung von Anführungs- und Escape-Zeichen:

    mysql> SELECT 'hello', '"hello"', '""hello""', 'hel''lo', '\'hello';
    +-------+---------+-----------+--------+--------+
    | hello | "hello" | ""hello"" | hel'lo | 'hello |
    +-------+---------+-----------+--------+--------+

    mysql> SELECT "hello", "'hello'", "''hello''", "hel""lo", "\"hello";
    +-------+---------+-----------+--------+--------+
    | hello | 'hello' | ''hello'' | hel"lo | "hello |
    +-------+---------+-----------+--------+--------+

    mysql> SELECT 'This\nIs\nFour\nLines';
    +--------------------+
    | This
    Is
    Four
    Lines |
    +--------------------+

    mysql> SELECT 'disappearing\ backslash';
    +------------------------+
    | disappearing backslash |
    +------------------------+

Wenn Sie Binärdaten in eine String-Spalte (z. B. eine `BLOB`-Spalte) einfügen wollen, müssen die folgenden Zeichen durch Escape-Sequenzen dargestellt werden:

`NUL` | `NUL`-Byte (ASCII 0). Dieses Zeichen wird mit ‘`\0`’ (einem Backslash gefolgt vom Zeichen ASCII ‘`0`’) dargestellt.
`\` | Backslash (ASCII 92). Stellen Sie dieses Zeichen als ‘`\\`’ dar.
`'` | Einfaches Anführungszeichen (ASCII 39). Stellen Sie dieses Zeichen als ‘`\'`’ dar.
`"` | Doppeltes Anführungszeichen (ASCII 34). Stellen Sie dieses Zeichen als ‘`\"`’ dar.

Wenn Sie Anwendungsprogramme schreiben, muss jeder String, der eines dieser Sonderzeichen enthalten kann, korrekt gekennzeichnet werden, bevor er als Datenwert in einer SQL-Anweisung verwendet wird, die an den MySQL Server gesendet wird. Dies lässt sich auf zweierlei Weise realisieren:

- Sie verarbeiten den String mit einer Funktion, die die Sonderzeichen entsprechend kennzeichnet. In einem C-Programm können Sie die C-API-Funktion `mysql_real_escape_string()` zur Kennzeichnung von Sonderzeichen verwenden. Siehe auch Abschnitt 24.2.3.52, „`mysql_real_escape_string()`“. Die Perl-DBI-Schnittstelle stellt eine Methode `quote` zur Konvertierung von Sonderzeichen in die entsprechenden Escape-Sequenzen bereit. Siehe auch Abschnitt 24.4, „MySQLs Perl-API“. Andere Spracheschnittstellen bieten unter Umständen ähnliche Funktionalitäten.

- Eine Alternative zur expliziten Kennzeichnung von Sonderzeichen stellt die Platzhalterfunktion dar, die von vielen MySQL-APIs geboten wird. Sie erlaubt Ihnen das Einfügen spezieller Markierungen in einen Anweisungs-String und das nachfolgende Binden der Datenwerte an diese Markierungen beim Absetzen der Anweisung. In diesem Fall nimmt Ihnen die API die Kennzeichnung der Sonderzeichen in den Werten ab.

### 9.1.2. Zahlen

Integer-Zahlen werden als Abfolge von Ziffern dargestellt. Fließkommazahlen verwenden den Punkt (‘`.`’) als Dezimaltrennzeichen. Bei allen Zahlentypen werden durch ein vorangestelltes ‘`-`’- oder ‘`+`’-Zeichen negative bzw. positive Werte angezeigt.

Beispiele gültiger Integers:

    1221
    0
    -32

Beispiele gültiger Fließkommazahlen:

    294.42
    -32032.6809e+10
    148.00

Ein Integer kann durchaus in einem Fließkommakontext angegeben werden. Er wird dann als die entsprechende Fließkommazahl interpretiert.

### 9.1.3. Hexadezimale Werte

MySQL unterstützt Hexadezimalwerte. In numerischen Kontexten verhalten sich diese wie Integers (mit 64-Bit-Präzision). In String-Kontexten hingegen agieren sie als binäre Strings, wobei jedes Hexadezimalziffernpaar in ein Zeichen umgewandelt wird:

    mysql> SELECT x'4D7953514C';
            -> 'MySQL'
    mysql> SELECT 0xa+0;
            -> 10
    mysql> SELECT 0x5061756c;
            -> 'Paul'

Der Standardtyp eines Hexadezimalwerts ist ein String. Wenn Sie gewährleisten wollen, dass der Wert als Zahl behandelt wird, können Sie `CAST(... AS UNSIGNED)` verwenden:

    mysql> SELECT 0x41, CAST(0x41 AS UNSIGNED);
            -> 'A', 65

Die Syntax `x'`hexstring`'` basiert auf Standard-SQL. Die Syntax `0x` basiert auf ODBC. Hexadezimal-Strings werden von ODBC häufig zur Angabe von Werten für `BLOB`-Spalten verwendet.

Sie können mit der Funktion `HEX()` einen String oder eine Zahl in einen String im Hexadezimalformat umwandeln:

    mysql> SELECT HEX('cat');
            -> '636174'
    mysql> SELECT 0x636174;
            -> 'cat'

### 9.1.4. Boolesche Werte

Die Konstanten `TRUE` und `FALSE` werden als `1` bzw. `0` ausgewertet. Bei den Konstantennamen wird die Groß-/Kleinschreibung nicht unterschieden.

    mysql> SELECT TRUE, true, FALSE, false;
            -> 1, 1, 0, 0

### 9.1.5. Bitfeldwerte

Bitfeldwerte können unter Verwendung der Notation `b'`value`'` geschrieben werden. Hierbei ist `value` ein Binärwert, der mit Nullen und Einsen notiert wird.

Die Bitfeldnotation ist zur Angabe von Werten nützlich, die `BIT`-Spalten zugewiesen werden sollen:

    mysql> CREATE TABLE t (b BIT(8));
    mysql> INSERT INTO t SET b = b'11111111';
    mysql> INSERT INTO t SET b = b'1010';
    +------+----------+----------+----------+
    | b+0  | BIN(b+0) | OCT(b+0) | HEX(b+0) |
    +------+----------+----------+----------+
    |  255 | 11111111 | 377      | FF       |
    |   10 | 1010     | 12       | A        |
    +------+----------+----------+----------+

### 9.1.6. `NULL`-Werte

Der Wert `NULL` bedeutet „keine Daten“. Die Groß-/Kleinschreibung wird bei `NULL` nicht unterschieden.

Beachten Sie, dass der `NULL`-Wert sich von Werten wie `0` für numerische Typen oder vom Leer-String für String-Typen unterscheidet. Siehe auch Abschnitt A.5.3, „Probleme mit `NULL`-Werten“.

Bei Import- oder Exportoperationen für Textdateien, die mit `LOAD DATA INFILE` oder `SELECT ... INTO OUTFILE` durchgeführt werden, wird `NULL` durch die Sequenz `\N` dargestellt. Siehe auch Abschnitt 13.2.5, „`LOAD DATA INFILE`“.

## 9.2. Datenbank-, Tabellen-, Index-, Spalten- und Aliasnamen

Namen von Datenbanken, Tabellen, Indizes, Spalten und Aliasen sind Bezeichner. Dieser Abschnitt beschreibt die für Bezeichner in MySQL zulässige Syntax.

Die folgende Tabelle beschreibt die Maximallänge und die erlaubten Zeichen für jeden Bezeichnertyp.

Bezeichner | Maximale Länge (in Byte) | Erlaubte Zeichen
Datenbank | 64 | Jedes Zeichen, das in einem Verzeichnisnamen zulässig ist. Ausgenommen sind ‘`/`’, ‘`\`’ und ‘`.`’
Tabelle | 64 | Jedes Zeichen, das in einem Dateinamen zulässig ist. Ausgenommen sind ‘`/`’, ‘`\`’ und ‘`.`’
Spalte | 64 | Alle Zeichen
Index | 64 | Alle Zeichen
Alias | 255 | Alle Zeichen

Neben den in der Tabelle genannten Einschränkungen dürfen Bezeichner weder das ASCII-Zeichen 0 noch ein Byte mit dem Wert 255 enthalten. Namen von Datenbanken, Tabellen und Spalten sollten nicht auf Leerzeichen enden. Die Verwendung von Anführungszeichen in Bezeichnern ist zulässig, sollte allerdings möglichst vermieden werden.

Bezeichner werden im Unicode-Format (UTF-8) gespeichert. Dies gilt für Bezeichner in Tabellendefinitionen, die in `.frm`-Dateien gespeichert sind, ebenso wie für solche in den Grant-Tabellen der Datenbank `mysql`. Die Länge der String-Spalten in den Grant-Tabellen (und in allen anderen Tabellen) in MySQL 5.1 wird als Anzahl von Zeichen angegeben. Das bedeutet, dass Sie (anders als bei älteren MySQL-Versionen) Multibytezeichen verwenden können, ohne die Anzahl der Zeichen verringern zu müssen, die für in diesen Spalten gespeicherte Werte erlaubt sind.

Ein Bezeichner kann mit und ohne Anführungszeichen geschrieben werden. Wenn ein Bezeichner ein reserviertes Wort ist oder Sonderzeichen enthält, müssen sie ihn bei jeder Referenzierung in Anführungszeichen setzen. (Ausnahme: Ein Wort, das auf einen Punkt in einem qualifizierten Namen folgt, muss ein Bezeichner sein; es muss also auch dann nicht in Anführungszeichen gesetzt werden, wenn es sich um ein reserviertes Wort handelt.) Eine Liste reservierter Wörter finden Sie unter Abschnitt 9.5, „Ist MySQL pingelig hinsichtlich reservierter Wörter?“. Als Sonderzeichen werden ‘`_`’ und ‘`$`’ sowie alle nicht alphanumerischen Zeichen des aktuellen Zeichensatzes betrachtet.

Das Anführungszeichen für Bezeichner ist der Backtick (‘```’):

    mysql> SELECT * FROM `select` WHERE `select`.id > 100;

Wenn der SQL-Modus `ANSI_QUOTES` aktiviert ist, können Sie Bezeichner auch in doppelte Anführungszeichen setzen:

    mysql> CREATE TABLE "test" (col INT);
    ERROR 1064: You have an error in your SQL syntax. (...)
    mysql> SET sql_mode='ANSI_QUOTES';
    mysql> CREATE TABLE "test" (col INT);
    Query OK, 0 rows affected (0.00 sec)

Hinweis: Da der Server bei aktiviertem `ANSI_QUOTES`-Modus Strings in doppelten Anführungszeichen in jedem Fall als Bezeichner interpretiert, müssen String-Literale in einfache Anführungszeichen gesetzt werden; doppelte Anführungszeichen dürfen in diesem Fall nicht für String-Literale verwendet werden.

Wie der SQL-Modus des Servers gesteuert wird, entnehmen Sie Abschnitt 5.2.5, „Der SQL-Modus des Servers“.

Anführungszeichen für Bezeichner können in einem Bezeichner enthalten sein, wenn Sie den Bezeichner in Anführungszeichen setzen. Wenn das im Bezeichner enthaltene Zeichen dasselbe ist, mit dem auch der Bezeichner selbst umschlossen ist, dann müssen Sie das Zeichen im Bezeichner verdoppeln. Die folgende Anweisung erstellt eine Tabelle namens `a`b`, die eine Spalte namens `c"d` enthält:

    mysql> CREATE TABLE `a``b` (`c"d` INT);

Es wird davon abgeraten, Namen des Formats ``M`e` oder ``M`e`N`` (wie etwa `1e` oder `2e2`) zu verwenden, weil ein Ausdruck wie `1e+3` nicht eindeutig ist: Abhängig vom Kontext kann er als Ausdruck `1e + 3` oder als Zahl `1e+3` interpretiert werden.

Seien Sie vorsichtig, wenn Sie mit `MD5()` Tabellennamen erstellen, da hiermit Namen in unzulässigen oder mehrdeutigen Formaten (so, wie gerade beschrieben) erzeugt werden können.

### 9.2.1. Qualifikatoren für Bezeichner

MySQL unterstützt Namen, die aus einem oder mehreren Bezeichnern bestehen. Die Bestandteile eines mehrteiligen Namens sollten durch Punkte (‘`.`’) getrennt werden. Die ersten Bestandteile eines mehrteiligen Namens agieren als Qualifikationsmerkmal, das den Kontext beeinflusst, in dem der endgültige Bezeichner interpretiert wird.

Bei MySQL können Sie eine Spalte auf jede der folgenden Weisen referenzieren:

Spaltenreferenzierung | Bedeutung
`col_name` | Die Spalte `col_name` einer in der Anweisung verwendeten Tabelle hat diesen Namen.
`tbl_name.col_name` | Die Spalte `col_name` der Tabelle `tbl_name` aus der Standarddatenbank.
`db_name.tbl_name.col_name` | Die Spalte `col_name` der Tabelle `tbl_name` aus der Datenbank `db_name`.

Wenn Bestandteile eines mehrteiligen Namens Anführungszeichen erfordern, müssen Sie diese Bestandteile einzeln (statt des gesamten Namens) in Anführungszeichen setzen. So ist etwa ``my-table`.`my-column`` zulässig – anders als ``my-table.my-column``.

Sie müssen das Präfix `tbl_name` oder `db_name.tbl_name` für eine Spaltenreferenzierung in einer Anweisung nicht angeben, sofern die Referenzierung eindeutig ist. Angenommen, die Tabellen `t1` und `t2` enthalten jeweils eine Spalte `c`. Nun wollen Sie `c` in einer `SELECT`-Anweisung abrufen, die sowohl `t1` als auch `t2` verwendet. In diesem Fall ist `c` unklar, weil es in Bezug auf die in der Anweisung angegebenen Tabellen nicht eindeutig ist. Sie müssen es mit einem Tabellennamen wie `t1.c` bzw. `t2.c` qualifizieren, um anzugeben, welche Tabelle Sie meinen. Analog müssen Sie, um Spaltenwerte aus einer Tabelle `t` in der Datenbank `db1` und einer Tabelle `t` in der Datenbank `db2` in einer Anweisung abzurufen, Spalten in diesen Tabellen als `db1.t.col_name` und `db2.t.col_name` referenzieren.

Ein Wort, das auf einen Punkt in einem qualifizierten Namen folgt, muss ein Bezeichner sein; es muss also auch dann nicht in Anführungszeichen gesetzt werden, wenn es sich um ein reserviertes Wort handelt.

Die Syntax `.tbl_name` bezeichnet die Tabelle `tbl_name` in der Standarddatenbank. Diese Syntax wird aus Gründen der ODBC-Kompatibilität akzeptiert, weil einige ODBC-Programme Tabellennamen das Zeichen ‘`.`’ voranstellen.

### 9.2.2. Groß-/Kleinschreibung in Namen

Bei MySQL entsprechen Datenbanken den Verzeichnissen im Datenverzeichnis. Jede Tabelle in einer Datenbank entspricht mindestens einer Datei (abhängig von der Speicher-Engine möglicherweise auch mehreren) im Datenbankverzeichnis. Hieraus folgt, dass bezüglich der Groß-/Kleinschreibung von Datenbank- und Tabellennamen die Regeln des zugrunde liegenden Betriebssystems beachtet werden müssen. Dies bedeutet, dass die Groß-/Kleinschreibung von Datenbank- und Tabellennamen bei den meisten Unix-Varianten unterschieden wird, bei Windows hingegen nicht. Eine beachtenswerte Ausnahme ist Mac OS X, welches zwar auf Unix basiert, standardmäßig aber einen Dateisystemtyp verwendet, der die Groß-/Kleinschreibung nicht unterscheidet. Allerdings unterstützt Mac OS X auch UFS-Volumes, die wie bei Unix üblich die Groß-/Kleinschreibung unterscheiden. Siehe auch Abschnitt 1.9.4, „MySQL-Erweiterungen zu ANSI SQL92“. Die Systemvariable `lower_case_table_names` beeinflusst ebenfalls die Vorgehensweise des Servers in Bezug auf die Groß-/Kleinschreibung bei Bezeichnern. Weitere Informationen hierzu folgen in diesem Abschnitt.

Hinweis: Zwar wird die Groß-/Kleinschreibung bei Datenbank- und Tabellennamen auf manchen Plattformen nicht unterschieden, aber Sie sollten eine gegebene Datenbank oder Tabelle auch nicht mit unterschiedlichen Schreibweisen innerhalb derselben Anweisung referenzieren. Die folgende Anweisung würde nicht funktionieren, weil sie eine Tabelle sowohl als `my_table` als auch als `MY_TABLE` referenziert:

    mysql> SELECT * FROM my_table WHERE MY_TABLE.col=1;

Bei Namen von Spalten, Indizes, gespeicherten Routinen und Triggern wird die Groß-/Kleinschreibung auf keiner Plattform unterschieden. Gleiches gilt für Spaltenaliase.

Standardmäßig wird die Groß-/Kleinschreibung bei Tabellenaliasen unter Unix, nicht aber unter Windows oder Mac OS X unterschieden. Die folgende Anweisung würde unter Unix nicht funktionieren, da sie einen Alias sowohl als `a` als auch als `A` referenziert:

    mysql> SELECT col_name FROM tbl_name AS a
        -> WHERE a.col_name = 1 OR A.col_name = 2;

Unter Windows hingegen ist diese Anweisung zulässig. Damit Sie diesen Unterschieden möglichst wenig Beachtung schenken müssen, sollten Sie am besten eine konsistente Benennungskonvention verwenden, in der Datenbanken und Tabellen immer mit aus Kleinbuchstaben bestehenden Namen erstellt und referenziert werden. Eine solche Konvention wird im Sinne maximaler Portabilität und Benutzerfreundlichkeit empfohlen.

Wie Tabellen- und Datenbanknamen auf Festplatte gespeichert und in MySQL verwendet werden, bestimmt die Systemvariable `lower_case_table_names`, die Sie beim Start von mysqld einstellen können. `lower_case_table_names` kann die in der nachfolgenden Tabelle aufgeführten Werte annehmen. Unter Unix ist der Standardwert von `lower_case_table_names` 0, unter Windows 1 und unter Mac OS X 2.

Wert | Bedeutung

`0`

Tabellen- und Datenbanknamen werden in der Schreibweise auf Festplatte gespeichert, die in der `CREATE TABLE`- bzw. `CREATE DATABASE`-Anweisung angegeben wurde. Beim Namensvergleich wird die Groß-/Kleinschreibung unterschieden. Beachten Sie, dass, wenn Sie diese Variable auf einem Dateisystem ohne Unterscheidung der Groß-/Kleinschreibung mit `--lower-case-table-names=0` explizit auf 0 setzen und dann `MyISAM`-Tabellen mit Namen in anderer Schreibung aufrufen, dies zu einer Beschädigung der Indizes führen kann.

`1` | Tabellennamen werden in Kleinbuchstaben auf Festplatte gespeichert. Beim Namensvergleich wird die Groß-/Kleinschreibung nicht unterschieden. MySQL konvertiert beim Speichern und Abrufen alle Tabellennamen in Kleinbuchstaben. Dieses Verhalten gilt auch für Datenbanknamen und Tabellenaliase.

`2`

Tabellen- und Datenbanknamen werden in der Schreibweise auf Festplatte gespeichert, die in der `CREATE TABLE`- bzw. `CREATE DATABASE`-Anweisung angegeben wurde; beim Nachschlagen konvertiert MySQL sie jedoch in Kleinbuchstaben. Beim Namensvergleich wird die Groß-/Kleinschreibung nicht unterschieden. Hinweis: Dies funktioniert nur auf Dateisystemen, die die Groß-/Kleinschreibung nicht unterscheiden! `InnoDB`-Tabellennamen werden in Kleinbuchstaben (wie bei `lower_case_table_names=1`) gespeichert.

Wenn Sie MySQL nur auf einer Plattform verwenden, dann müssen Sie die Variable `lower_case_table_names` normalerweise nicht umstellen. Allerdings kann es zu Problemen kommen, wenn Sie Tabellen auf andere Plattformen mit unterschiedlicher Behandlung der Groß-/Kleinschreibung portieren wollen. So können Sie unter Unix beispielsweise zwei verschiedene Tabellen mit den Namen `my_table` und `MY_TABLE` verwenden; unter Windows jedoch werden diese beiden Namen als identisch betrachtet. Um Transferprobleme aufgrund der Schreibweise von Datenbank- oder Tabellennamen zu vermeiden, haben Sie zwei Optionen:

- Sie verwenden `lower_case_table_names=1` auf allen Systemen. Der wesentliche Nachteil besteht hierbei darin, dass Sie, wenn Sie `SHOW TABLES` bzw. `SHOW DATABASES` verwenden, die Namen nicht in der ursprünglichen Schreibweise angezeigt bekommen.

- Sie verwenden unter Unix `lower_case_table_names=0` und unter Windows `lower_case_table_names=2`. Hierdurch wird die Schreibweise von Datenbank- und Tabellennamen beibehalten. Allerdings müssen Sie in diesem Fall gewährleisten, dass Ihre Anweisungen unter Windows die korrekte Schreibweise für Datenbank- und Tabellennamen enthalten. Wenn Sie Ihre Anweisungen dann auf Unix übertragen, wo die Groß-/Kleinschreibung unterschieden wird, dann funktionieren sie aufgrund der falschen Schreibweise nicht mehr.

  Ausnahme: Wenn Sie `InnoDB`-Tabellen verwenden, sollten Sie `lower_case_table_names` auf allen Plattformen auf 1 setzen. Hiermit wird die Konvertierung von Namen in die Kleinschreibung erzwungen.

Beachten Sie, dass Sie, wenn Sie die Systemvariable `lower_case_table_names` unter Unix auf 1 setzen wollen, zunächst Ihre alten Datenbank- und Tabellennamen in die Kleinschreibung konvertieren müssen, bevor Sie mysqld mit der neuen Variableneinstellung neu starten.

## 9.3. Benutzerdefinierte Variablen

Sie können einen Wert in einer Benutzervariablen speichern und diese dann später referenzieren. Auf diese Weise können Sie Werte von einer Anweisung an eine andere übergeben. Benutzerdefinierte Variablen sind verbindungsspezifisch, d. h., eine Benutzervariable, die von einem Client definiert wurde, wird von anderen Clients nicht gesehen und kann von diesen auch nicht verwendet werden. Alle Variablen einer gegebenen Clientverbindung werden automatisch freigegeben, wenn diese Verbindung beendet wird.

Benutzervariablen werden als `@`var_name`` notiert, wobei der Variablenname `var_name` aus alphanumerischen Zeichen des aktuellen Zeichensatzes sowie ‘`.`’, ‘`_`’ und ‘`$`’ bestehen kann. Der Standardzeichensatz ist `latin1` (cp1252 West European). Er lässt sich mit der Option `--default-character-set` für mysqld ändern. Siehe auch Abschnitt 5.11.1, „Der für Daten und zum Sortieren benutzte Zeichensatz“. Der Name einer Benutzervariablen darf auch andere Zeichen enthalten, wenn Sie ihn als String oder Bezeichner in Anführungszeichen setzen (z. B. `@'my-var'`, `@"my-var"` oder `@`my-var``).

Hinweis: Bei MySQL vor Version 5.0 wird die Groß-/Kleinschreibung unterschieden, ab MySQL 5.0 hingegen nicht mehr.

Eine Möglichkeit zur Einstellung einer benutzerdefinierten Variablen besteht im Absetzen einer `SET`-Anweisung:

    SET @var_name = expr [, @var_name = expr] ...

Bei `SET` kann entweder `=` oder `:=` als Zuweisungsoperator verwendet werden. Der Wert `expr` einer Variablen kann als Integer, reale Zahl, String oder `NULL`-Wert ausgewertet werden.

Sie können einer Benutzervariablen auch mit einer anderen Anweisung als `SET` einen Wert zuweisen. In diesem Fall muss der Zuweisungsoperator `:=` sein; `=` darf nicht verwendet werden, da es in anderen Anweisungen als `SET` als Vergleichsoperator benutzt wird:

    mysql> SET @t1=0, @t2=0, @t3=0;
    mysql> SELECT @t1:=(@t2:=1)+@t3:=4,@t1,@t2,@t3;
    +----------------------+------+------+------+
    | @t1:=(@t2:=1)+@t3:=4 | @t1  | @t2  | @t3  |
    +----------------------+------+------+------+
    |                    5 |    5 |    1 |    4 |
    +----------------------+------+------+------+

Benutzervariablen können in Kontexten eingesetzt werden, in denen Ausdrücke zulässig sind. Hierzu gehören zurzeit keine Kontexte, die explizit einen literalen Wert erfordern, also beispielsweise die `LIMIT`-Klausel einer `SELECT`-Anweisung oder die `IGNORE `N` LINES`-Klausel einer `LOAD DATA`-Anweisung.

Wenn einer Benutzervariablen ein String-Wert zugewiesen wird, hat sie denselben Zeichensatz und dieselbe Sortierung wie dieser String. Die Erzwingbarkeit ist Benutzervariablen implizit. (Es handelt sich um dieselbe Erzwingbarkeit wie bei Werten einer Tabellenspalte.)

Hinweis: In einer `SELECT`-Anweisung wird jeder Ausdruck erst dann ausgewertet, wenn er an den Client gesendet wird. Das bedeutet, dass in einer `HAVING`-, `GROUP BY`- oder `ORDER BY`-Klausel keine Referenzierung eines Ausdrucks möglich ist, der Variablen beinhaltet, die in der `SELECT`-Liste eingestellt werden. Die folgende Anweisung beispielsweise funktioniert nicht wie erwartet:

    mysql> SELECT (@aa:=id) AS a, (@aa+3) AS b FROM tbl_name HAVING b=5;

Die Referenzierung von `b` in der `HAVING`-Klausel verweist auf ein Alias eines Ausdrucks in der `SELECT`-Liste, die `@aa` verwendet. Das funktioniert nicht so, wie man es eigentlich erwarten würde: `@aa` enthält den Wert von `id` aus dem zuvor ausgewählten (und nicht dem aktuellen) Datensatz.

Allgemein gesagt darf man niemals einer Benutzervariablen in einem Teil einer Anweisung einen Wert zuweisen und dieselbe Variable in einem anderen Teil derselben Anweisung verwenden. Vielleicht erhalten Sie die erwarteten Ergebnisse, aber dies ist nicht sicher.

Ein weiteres Problem in Zusammenhang mit der Einstellung einer Variablen und ihrer Verwendung in derselben Anweisung besteht darin, dass der standardmäßige Ergebnistyp einer Variablen zu Beginn der Anweisung auf dem Variablentyp basiert. Das folgende Beispiel veranschaulicht dies:

    mysql> SET @a='test';
    mysql> SELECT @a,(@a:=20) FROM tbl_name;

Bei dieser `SELECT`-Anweisung meldet MySQL dem Client, dass Spalte eins ein String ist, und konvertiert alle Zugriffe auf `@a` in Strings, obwohl `@a` für den zweiten Datensatz eine Zahlenmenge ist. Nachdem die `SELECT`-Anweisung ausgeführt wurde, wird `@a` für die nächste Anweisung als Zahl betrachtet.

Um Probleme in Zusammenhang mit diesem Verhalten zu vermeiden, sollten Sie entweder dieselbe Variable nicht gleichzeitig in ein und derselben Anweisung einstellen und verwenden oder aber die Variable auf `0`, `0.0` oder `''` setzen, um vor ihrer Verwendung den Typ zu definieren.

Wenn Sie eine Variable referenzieren, die noch nicht initialisiert wurde, dann hat diese den Wert `NULL`, und der Variablentyp ist ein String.

## 9.4. Kommentar

Der MySQL Server unterstützt drei Kommentarstile:

- Vom Zeichen ‘`#`’ bis zum Zeilenende.

- Von der Sequenz ‘`--` ’ bis zum Zeilenende. Bei MySQL erfordert der Kommentarstil ‘`--` ’ (doppelter Bindestrich) mindestens ein nachfolgendes Whitespace- oder Steuerzeichen (z. B. ein Leerzeichen, einen Tabulator, einen Zeilenwechsel usw.). Diese Syntax unterscheidet sich leicht von der SQL-Standardkommentarsyntax, wie sie in Abschnitt 1.9.5.7, „'`--`' als Beginn eines Kommentars“, beschrieben ist.

- Von der Sequenz `/*` bis zur folgenden Sequenz `*/`, wie man es von der Programmiersprache C her kennt. Diese Syntax ermöglicht Kommentare, die sich über mehrere Zeilen erstrecken, da öffnende und schließende Sequenz nicht in derselben Zeile stehen müssen.

Das folgende Beispiel veranschaulicht alle drei Kommentarstile:

    mysql> SELECT 1+1;     # This comment continues to the end of line
    mysql> SELECT 1+1;     -- This comment continues to the end of line
    mysql> SELECT 1 /* this is an in-line comment */ + 1;
    mysql> SELECT 1+
    /*
    this is a
    multiple-line comment
    */
    1;

MySQL Server unterstützt mehrere Kommentarvarianten im C-Stil. Hiermit 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 beschriebene Kommentarsyntax wirkt sich darauf aus, wie der Server mysqld SQL-Anweisungen verarbeitet. Auch das Clientprogramm mysql verarbeitet die Anweisungen teilweise, bevor es sie an den Server sendet. (Dies tut es, um die Anweisungsgrenzen in einer Eingabezeile mit mehreren Anweisungen zu ermitteln.)

## 9.5. Ist MySQL pingelig hinsichtlich reservierter Wörter?

Ein häufig auftretendes Problem liegt vor, wenn Sie einen Bezeichner (z. B. einen Tabellen- oder Datenbanknamen) verwenden wollen, der ein reserviertes Wort wie `SELECT` oder den Namen eines werksseitig vorhandenen MySQL-Datentyps oder einer Funktion wie `TIMESTAMP` oder `GROUP` enthält.

Wenn ein Bezeichner ein reserviertes Wort ist, müssen Sie ihn wie in Abschnitt 9.2, „Datenbank-, Tabellen-, Index-, Spalten- und Aliasnamen“, beschrieben in Anführungszeichen setzen. Ausnahme: Ein Wort, das auf einen Punkt in einem qualifizierten Namen folgt, muss ein Bezeichner sein; es muss also auch dann nicht in Anführungszeichen gesetzt werden, wenn es sich um ein reserviertes Wort handelt.

Funktionsnamen dürfen Sie als Bezeichner verwenden. Beispielsweise ist `ABS` als Spaltenname zulässig. Standardmäßig ist nämlich bei Funktionsaufrufen kein Whitespace zwischen dem Funktionsnamen und dem nachfolgenden Zeichen ‘`(`’ zulässig; auf diese Weise kann ein Funktionsaufruf von der Referenzierung eines Spaltennamens unterschieden werden.

Eine Begleiterscheinung dieses Verhaltens besteht darin, dass das Weglassen eines Leerzeichens in manchen Kontexten dazu führen kann, dass ein Bezeichner als Funktionsname interpretiert wird. Folgende Anweisung beispielsweise ist zulässig:

    mysql> CREATE TABLE abs (val INT);

Das Weglassen des Leerzeichens nach `abs` verursacht einen Syntaxfehler, da die Anweisung in diesem Fall die Funktion `ABS()` aufzurufen scheint:

    mysql> CREATE TABLE abs(val INT);
    ERROR 1064 (42000) at line 2: You have an error in your SQL
    syntax ... near 'abs(val INT)'

Ist der SQL-Modus `IGNORE_SPACE` aktiviert, dann gestattet der Server bei Funktionsaufrufen das Vorhandensein von Whitespace zwischen dem Funktionsnamen und dem nachfolgenden Zeichen ‘`(`’. Hierdurch werden Funktionsnamen als reservierte Wörter behandelt. Infolgedessen müssen Bezeichner, die mit Funktionsnamen identisch sind, wie in Abschnitt 9.2, „Datenbank-, Tabellen-, Index-, Spalten- und Aliasnamen“, beschrieben in Anführungszeichen gesetzt werden. Wie der SQL-Modus des Servers gesteuert wird, entnehmen Sie Abschnitt 5.2.5, „Der SQL-Modus des Servers“.

Die Wörter in der folgenden Tabelle sind explizit für MySQL 5.1 reserviert. Für den Fall, dass Sie später einmal auf eine höhere Version zu aktualisieren beabsichtigen, sollten Sie auch solche Wörter beachten, die in Zukunft reserviert sein werden. Sie finden diese in den Handbüchern zu höheren MySQL-Versionen. Die meisten der Wörter in der Tabelle sind in Standard-SQL als Spalten- oder Tabellennamen unzulässig (z. B. `GROUP`). Einige der Wörter sind auch reserviert, weil MySQL sie benötigt und (derzeit) einen yacc-Parser verwendet. Ein reserviertes Wort darf als Bezeichner verwendet werden, wenn Sie es in Anführungszeichen setzen.

`ACCESSIBLE` | `ADD` | `ALL`
`ALTER` | `ANALYZE` | `AND`
`AS` | `ASC` | `ASENSITIVE`
`BEFORE` | `BETWEEN` | `BIGINT`
`BINARY` | `BLOB` | `BOTH`
`BY` | `CALL` | `CASCADE`
`CASE` | `CHANGE` | `CHAR`
`CHARACTER` | `CHECK` | `COLLATE`
`COLUMN` | `CONDITION` | `CONNECTION`
`CONSTRAINT` | `CONTINUE` | `CONVERT`
`CREATE` | `CROSS` | `CURRENT_DATE`
`CURRENT_TIME` | `CURRENT_TIMESTAMP` | `CURRENT_USER`
`CURSOR` | `DATABASE` | `DATABASES`
`DAY_HOUR` | `DAY_MICROSECOND` | `DAY_MINUTE`
`DAY_SECOND` | `DEC` | `DECIMAL`
`DECLARE` | `DEFAULT` | `DELAYED`
`DELETE` | `DESC` | `DESCRIBE`
`DETERMINISTIC` | `DISTINCT` | `DISTINCTROW`
`DIV` | `DOUBLE` | `DROP`
`DUAL` | `EACH` | `ELSE`
`ELSEIF` | `ENCLOSED` | `ESCAPED`
`EXISTS` | `EXIT` | `EXPLAIN`
`FALSE` | `FETCH` | `FLOAT`
`FLOAT4` | `FLOAT8` | `FOR`
`FORCE` | `FOREIGN` | `FROM`
`FULLTEXT` | `GRANT` | `GROUP`
`HAVING` | `HIGH_PRIORITY` | `HOUR_MICROSECOND`
`HOUR_MINUTE` | `HOUR_SECOND` | `IF`
`IGNORE` | `IN` | `INDEX`
`INFILE` | `INNER` | `INOUT`
`INSENSITIVE` | `INSERT` | `INT`
`INT1` | `INT2` | `INT3`
`INT4` | `INT8` | `INTEGER`
`INTERVAL` | `INTO` | `IS`
`ITERATE` | `JOIN` | `KEY`
`KEYS` | `KILL` | `LEADING`
`LEAVE` | `LEFT` | `LIKE`
`LIMIT` | `LINEAR` | `LINES`
`LOAD` | `LOCALTIME` | `LOCALTIMESTAMP`
`LOCK` | `LONG` | `LONGBLOB`
`LONGTEXT` | `LOOP` | `LOW_PRIORITY`
`MATCH` | `MEDIUMBLOB` | `MEDIUMINT`
`MEDIUMTEXT` | `MIDDLEINT` | `MINUTE_MICROSECOND`
`MINUTE_SECOND` | `MOD` | `MODIFIES`
`NATURAL` | `NOT` | `NO_WRITE_TO_BINLOG`
`NULL` | `NUMERIC` | `ON`
`OPTIMIZE` | `OPTION` | `OPTIONALLY`
`OR` | `ORDER` | `OUT`
`OUTER` | `OUTFILE` | `PRECISION`
`PRIMARY` | `PROCEDURE` | `PURGE`
`RANGE` | `READ` | `READS`
`READ_ONLY` | `READ_WRITE` | `REAL`
`REFERENCES` | `REGEXP` | `RELEASE`
`RENAME` | `REPEAT` | `REPLACE`
`REQUIRE` | `RESTRICT` | `RETURN`
`REVOKE` | `RIGHT` | `RLIKE`
`SCHEMA` | `SCHEMAS` | `SECOND_MICROSECOND`
`SELECT` | `SENSITIVE` | `SEPARATOR`
`SET` | `SHOW` | `SMALLINT`
`SPATIAL` | `SPECIFIC` | `SQL`
`SQLEXCEPTION` | `SQLSTATE` | `SQLWARNING`
`SQL_BIG_RESULT` | `SQL_CALC_FOUND_ROWS` | `SQL_SMALL_RESULT`
`SSL` | `STARTING` | `STRAIGHT_JOIN`
`TABLE` | `TERMINATED` | `THEN`
`TINYBLOB` | `TINYINT` | `TINYTEXT`
`TO` | `TRAILING` | `TRIGGER`
`TRUE` | `UNDO` | `UNION`
`UNIQUE` | `UNLOCK` | `UNSIGNED`
`UPDATE` | `USAGE` | `USE`
`USING` | `UTC_DATE` | `UTC_TIME`
`UTC_TIMESTAMP` | `VALUES` | `VARBINARY`
`VARCHAR` | `VARCHARACTER` | `VARYING`
`WHEN` | `WHERE` | `WHILE`
`WITH` | `WRITE` | `X509`
`XOR` | `YEAR_MONTH` | `ZEROFILL`

Folgende reservierte Wörter sind neu in MySQL 5.1:

`ACCESSIBLE` | `LINEAR` | `RANGE`
`READ_ONLY` | `READ_WRITE` |

MySQL gestattet auch die Verwendung bestimmter Schlüsselwörter als Bezeichner ohne Anführungszeichen, da viele Benutzer sie in der Vergangenheit bereits eingesetzt haben. Beispiele entnehmen Sie der folgenden Liste:

- `ACTION`

- `BIT`

- `DATE`

- `ENUM`

- `NO`

- `TEXT`

- `TIME`

- `TIMESTAMP`

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
Kapitel 8. Client- und Hilfsprogramme | Zum Anfang | Kapitel 10. Zeichensatz-Unterstützung