Movatterモバイル変換

MySQL 5.7 Reference Manual

8.12.3.2 Using Symbolic Links for MyISAM Tables on Unix

Symlinks are fully supported only forMyISAM tables. For files used by tables for other storage engines, you may get strange problems if you try to use symbolic links. ForInnoDB tables, use the alternative technique explained inSection 14.6.1.2, “Creating Tables Externally” instead.

Do not symlink tables on systems that do not have a fully operationalrealpath() call. (Linux and Solaris supportrealpath()). To determine whether your system supports symbolic links, check the value of thehave_symlink system variable using this statement:

SHOW VARIABLES LIKE 'have_symlink';

The handling of symbolic links forMyISAM tables works as follows:

In the data directory, you always have the table format (.frm) file, the data (.MYD) file, and the index (.MYI) file. The data file and index file can be moved elsewhere and replaced in the data directory by symlinks. The format file cannot.
You can symlink the data file and the index file independently to different directories.
To instruct a running MySQL server to perform the symlinking, use theDATA DIRECTORY andINDEX DIRECTORY options toCREATE TABLE. SeeSection 13.1.18, “CREATE TABLE Statement”. Alternatively, ifmysqld is not running, symlinking can be accomplished manually usingln -s from the command line.
Note
The path used with either or both of theDATA DIRECTORY andINDEX DIRECTORY options may not include the MySQLdata directory. (Bug #32167)
myisamchk does not replace a symlink with the data file or index file. It works directly on the file to which the symlink points. Any temporary files are created in the directory where the data file or index file is located. The same is true for theALTER TABLE,OPTIMIZE TABLE, andREPAIR TABLE statements.
Note
When you drop a table that is using symlinks,both the symlink and the file to which the symlink points are dropped. This is an extremely good reasonnot to runmysqld as theroot operating system user or permit operating system users to have write access to MySQL database directories.
If you rename a table withALTER TABLE ... RENAME orRENAME TABLE and you do not move the table to another database, the symlinks in the database directory are renamed to the new names and the data file and index file are renamed accordingly.
If you useALTER TABLE ... RENAME orRENAME TABLE to move a table to another database, the table is moved to the other database directory. If the table name changed, the symlinks in the new database directory are renamed to the new names and the data file and index file are renamed accordingly.
If you are not using symlinks, startmysqld with the--skip-symbolic-links option to ensure that no one can usemysqld to drop or rename a file outside of the data directory.

These table symlink operations are not supported:

ALTER TABLE ignores theDATA DIRECTORY andINDEX DIRECTORY table options.
As indicated previously, only the data and index files can be symbolic links. The.frm file mustnever be a symbolic link. Attempting to do this (for example, to make one table name a synonym for another) produces incorrect results. Suppose that you have a databasedb1 under the MySQL data directory, a tabletbl1 in this database, and in thedb1 directory you make a symlinktbl2 that points totbl1:
```
$> cd/path/to/datadir/db1$> ln -s tbl1.frm tbl2.frm$> ln -s tbl1.MYD tbl2.MYD$> ln -s tbl1.MYI tbl2.MYI
```
Problems result if one thread readsdb1.tbl1 and another thread updatesdb1.tbl2:
- The query cache is“fooled” (it has no way of knowing thattbl1 has not been updated, so it returns outdated results).
- ALTER statements ontbl2 fail.

PREV HOME UP NEXT