Skip navigation links
MySQL 5.1 Referenzhandbuch :: 7 Optimierung :: 7.6 Festplatte, Anmerkungen :: 7.6.1 Symbolische Verknüpfungen :: 7.6.1.2 Benutzung symbolischer Links für Tabellen
7.6.1.3 Daten unter Windows auf verschiedene Platten aufteilen »
Section Navigation      [Toggle]

7.6.1.2. Benutzung symbolischer Links für Tabellen

Auf Systemen, die keinen vollständig funktionsfähigen realpath()-Aufruf aufweisen, sollten Sie Tabellen nicht symbolisch verknüpfen. (Linux und Solaris unterstützen realpath().) Sie können überprüfen, ob Ihr System symbolische Verknüpfungen unterstützt, indem Sie eine SHOW VARIABLES LIKE 'have_symlink'-Anweisung absetzen.

Symbolische Verknüpfungen werden nur bei MyISAM-Tabellen vollständig unterstützt. Bei Dateien, die von auf anderen Speicher-Engines basierenden Tabellen verwendet werden, werden Sie seltsame Probleme bekommen, wenn Sie versuchen, symbolische Verknüpfungen zu verwenden.

Die Verarbeitung symbolischer Verknüpfungen für MyISAM-Tabellen funktioniert wie folgt:

  • Im Datenverzeichnis befinden sich immer die Tabellenformatdatei (.frm-Datei), die Datendatei (.MYD-Datei) und die Indexdatei (.MYI-Datei). Die Daten- und die Indexdatei können an eine andere Position verschoben und durch symbolische Verknüpfungen im Datenverzeichnis ersetzt werden. Für die Formatdatei ist dies nicht möglich.

  • Sie können die Daten- und die Indexdatei separat in verschiedene Verzeichnisse verschieben und durch Verknüpfungen ersetzen.

  • Sie können einen laufenden MySQL Server anweisen, die symbolischen Verknüpfungen mithilfe der Optionen DATA DIRECTORY und INDEX DIRECTORY für CREATE TABLE zu erstellen. Siehe auch Abschnitt 13.1.5, „CREATE TABLE“. Alternativ können die Verknüpfungen mithilfe von ln -s auch manuell über die Befehlszeile eingerichtet werden, wenn mysqld nicht ausgeführt wird.

  • myisamchk ersetzt eine symbolische Verknüpfung nicht durch die Daten- oder Indexdatei, sondern bearbeitet direkt die Datei, auf die die Verknüpfung verweist. Temporärdateien werden in dem Verzeichnis erstellt, in dem sich die Daten- bzw. Indexdatei befindet.

  • Hinweis: Wenn Sie eine Tabelle löschen, die symbolische Verknüpfungen erstellt, dann werden sowohl die Verknüpfung als auch die Datei, auf die die Verknüpfung verweist, gelöscht. Dies ist ein ausgesprochen triftiger Grund, warum Sie mysqld nicht als root des Systems ausführen oder Benutzern Schreibzugriff auf die MySQL-Datenbankverzeichnisse gewähren sollten.

  • Wenn Sie eine Tabelle mit ALTER TABLE … RENAME umbenennen und sie nicht in einer Datenbank verschieben, werden die symbolischen Verknüpfungen im Datenbankverzeichnis auf die neuen Namen umgestellt und die Daten- und Indexdatei entsprechend umbenannt.

  • Verwenden Sie ALTER TABLE … RENAME zur Verschiebung einer Tabelle in eine andere Datenbank, dann wird die Tabelle in das andere Datenbankverzeichnis verschoben. Die alten Verknüpfungen und die Dateien, auf die sie verwiesen, werden gelöscht. Dies bedeutet, dass es für die neue Tabelle keine symbolische Verknüpfung gibt.

  • Wenn Sie keine symbolischen Verknüpfungen verwenden, sollten Sie die Option --skip-symbolic-links für mysqld einsetzen, um zu gewährleisten, dass niemand mit mysqld eine Datei außerhalb des Datenverzeichnisses löschen oder umbenennen kann.

Die folgenden tabellenbezogenen Operationen in Verbindung mit symbolischen Verknüpfungen werden noch nicht unterstützt:

  • ALTER TABLE ignoriert die Tabellenoptionen DATA DIRECTORY und INDEX DIRECTORY.

  • BACKUP TABLE und RESTORE TABLE beachten symbolische Verknüpfungen nicht.

  • Die .frm-Datei darf niemals eine symbolische Verknüpfung sein (wie oben bereits angemerkt; nur Daten- und Indexdateien dürfen symbolische Verknüpfungen sein). Wenn Sie dies trotzdem versuchen (um beispielsweise Synonyme zu erstellen), dann erhalten Sie falsche Ergebnisse. Angenommen, Sie haben eine Datenbank db1 im MySQL-Datenverzeichnis und eine Tabelle tbl1 in dieser Datenbank. Nun erstellen Sie im Verzeichnis db1 eine symbolische Verknüpfung tbl2, die auf tbl1 verweist: 

    shell> cd /path/to/datadir/db1
shell> ln -s tbl1.frm tbl2.frm
shell> ln -s tbl1.MYD tbl2.MYD
shell> ln -s tbl1.MYI tbl2.MYI

    Probleme treten auf, wenn ein Thread db1.tbl1 liest und ein anderer db1.tbl2 aktualisiert:

    • Der Abfrage-Cache wird „hintergangen“ (denn er kann nicht wissen, dass tbl1 nicht geändert wurde, und gibt aufgrund dessen veraltete Ergebnisse zurück).

    • ALTER-Anweisungen für tbl2 schlagen ebenfalls fehl.

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.