Inhaltsverzeichnis
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
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.
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
' [COLLATEcollation_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:
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
verwenden.
db_name
<
file_name
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.
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.
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'
basiert auf Standard-SQL. Die Syntax hexstring
'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'
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
Bitfeldwerte können unter Verwendung der Notation
b'
geschrieben werden. Hierbei ist value
'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 | +------+----------+----------+----------+
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
“.
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
oder
M
e
(wie etwa M
eN
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.
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.
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
FROMtbl_name
AS aWHERE 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.
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
@
notiert,
wobei der Variablenname var_name
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
-Klausel einer
N
LINESLOAD 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.
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.)
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 | 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 | MASTER_SSL_VERIFY_SERVER_CERT |
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 | MASTER_SSL_VERIFY_SERVER_CERT |
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.