[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4. データベース管理

4.1 MySQL のコンフィギャ   
4.2 同じマシン上で複数の MySQL サーバを実行する   
4.3 一般的なセキュリティ関連事項と MySQL アクセス制御システム   
4.4 MySQL のユーザ管理   
4.5 障害の予防とリカバリ   
4.6 データベース管理言語リファレンス   
4.7 MySQL のローカライズと国際的な使用   
4.8 MySQL サーバサイドのスクリプトとユーティリティ   
4.9 MySQL クライアントサイドのスクリプトとユーティリティ   
4.10 MySQL ログファイル   
4.11 MySQL のレプリケーション   

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.1 MySQL のコンフィギャ

4.1.1 mysqld コマンドラインオプション   
4.1.2 `my.cnf' オプション設定ファイル   

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.1.1 mysqld コマンドラインオプション

通常、mysqld オプションはオプション設定ファイルから管理してください。 「4.1.2 `my.cnf' オプション設定ファイル」 節 参照 。

mysqld と mysqld.server は mysqld グループと server グループからオプションを読み込みます。 mysqld_safe は mysqld、server、mysqld_safe、safe_mysqld の各グループからオプションを読み込みます。 組み込み MySQL サーバは通常、server、embedded、および xxxxx_SERVER からオプションを読み込みます。ここで、xxxxx はアプリケーションの名前です。

mysqld には、多くのコマンドラインオプションがあります。以下、一般的なコマンドラインオプションについて説明します。 完全なオプション一覧を参照するには、mysqld --help を実行してください。 レプリケーション用のオプションについては、別のセクションで説明します。 「4.11.6 レプリケーションスタートアップオプション」 を参照してください。

--ansi
MySQL 構文ではなく、SQL-99 構文を使用する。 「1.8.2 ANSI モードでの MySQL の実行」 節 参照 。

-b, --basedir=path
インストールディレクトリのパス。すべてのパスは通常、このパスからの相対パスで解決される。

--big-tables
すべてのテンポラリセットをファイルに保存することにより、大きな結果セットを可能にする。これによりほとんどの 'table full' エラーが解決されるが、メモリ内テーブルだけで事足りるクエリの実行速度も遅くなる。MySQL バージョン 3.23.2 以降、小さなテンポラリテーブルの場合はメモリを使用し、必要に応じて自動的にディスクテーブルに切り替わるようになっている。

--bind-address=IP
バインドする IP アドレス。

--console
--log-error が指定されている場合でも、stderr/stdout にエラーログメッセージを書き込む。このオプションを使用した場合、Windows では mysqld によりコンソール画面が開かれたままになる。

--character-sets-dir=path
キャラクタセットが格納されているディレクトリ。 「4.7.1 データおよびソート用キャラクタセット」 節 参照 。

--chroot=path
起動時に chroot 環境に mysqld デーモンを配置する。MySQL 4.0 以降の推奨セキュリティ設定（MySQL 3.23 では、完全に閉じた chroot ジェイルを提供できない）。 ただし、LOAD DATA INFILE と SELECT ... INTO OUTFILE に制約が加わる。

--core-file
mysqld が異常終了した場合に、コアファイルを作成する。システムによっては、mysqld_safe に --core-file-size を指定することも必要になる。 「4.8.2 mysqld_safe（mysqld のラッパ）」 節 参照 。 注意: --user オプションも使用している場合、Solaris などシステムではコアファイルを作成できない。

-h, --datadir=path
データベースルートのパス。

--debug[...]=
MySQL を --with-debug でコンフィギャしている場合、このオプションを使用して mysqld の動作を示すトレースファイルを取得できる。 「E.1.2 トレースファイルの作成」 節 参照 。

--default-character-set=charset
デフォルトのキャラクタセットを設定する。 「4.7.1 データおよびソート用キャラクタセット」 節 参照 。

--default-table-type=type
デフォルトのテーブル型を設定する。 「7. MySQL のテーブル型」 節 参照 。

--delay-key-write[= OFF | ON | ALL]
MyISAM で、DELAYED KEYS をどのように使用するか指定する。 「5.5.2 サーバパラメータのチューニング」 節 参照 。

--delay-key-write-for-all-tables（MySQL 4.0.3 では、--delay-key-write=ALL を使用）
すべての MyISAM テーブルにおいて、書き込み間のキーバッファをフラッシュしない。 「5.5.2 サーバパラメータのチューニング」 節 参照 。

--des-key-file=filename
DES_ENCRYPT() および DES_DECRYPT() が使用するデフォルトキーをこのファイルから読み取る。

--enable-external-locking（以前は --enable-locking）
システムロックを有効にする。注意: lockd が完全には機能しないシステム（Linux など）でこのオプションを使用すると、mysqld がデッドロックになる可能性が高くなる。

--enable-named-pipe
名前付きパイプのサポートを有効化する（Windows NT/2000/XP のみ）。

-T, --exit-info
mysqld サーバのデバッグに使用できる、複数の異なるフラグのビットマスク。完全に理解していない限り、このオプションは使用しないこと。

--flush
各 SQL コマンド実行後、ディスクへの変更をすべてフラッシュする。通常、MySQL は各 SQL コマンドの後、ディスクへの変更の書き込みだけを行い、ディスクへの同期処理はオペレーティングシステムに任せる。 「A.4.1 MySQL が何度もクラッシュする場合に行うこと」 節 参照 。

-?, --help
ショートヘルプを表示して終了する。

--init-file=file
起動時に、このファイルから SQL コマンドを読み取る。

-L, --language=...
クライアントエラーメッセージに使用する言語。フルパスで指定できる。 「4.7.2 英語以外のエラーメッセージ」 節 参照 。

-l, --log[=file]
接続とクエリをログファイルに記録する。 「4.10.2 一般クエリログ」 節 参照 。

--log-bin=[file]
データを変更するクエリをすべてログファイルに記録する。バックアップおよびレプリケーション用に使用する。 「4.10.4 バイナリログ」 節 参照 。

--log-bin-index[=file]
バイナリログファイル名のインデックスファイル。 「4.10.4 バイナリログ」 節 参照 。

--log-error[=file]
エラーメッセージおよびスタートアップメッセージをこのログファイルに記録する。 「4.10.1 エラーログ」 節 参照 。

--log-isam[=file]
ISAM および MyISAM の変更をすべてログファイルに記録する（ISAM および MyISAM のデバッグ時のみ使用）。

--log-long-format
追加情報をログファイルに記録する（更新ログ、バイナリ更新ログ、スロークエリログなど、有効化されているすべてのログ）。たとえば、クエリのユーザ名とタイムスタンプが記録される。--log-slow-queries と --log-long-format を使用している場合、インデックスを使用しないクエリも、スロークエリログに記録される。 注意: --log-long-format は MySQL バージョン 4.1 で廃止され、--log-short-format が導入されている（long log format がバージョン 4.1 以降のデフォルト設定になった）。また、MySQL 4.1 から、インデックスを使用しないクエリをスロークエリログに記録するための --log-queries-not-using-indexes オプションが利用可能になっている。

--log-queries-not-using-indexes
このオプションを --log-slow-queries と一緒に使用すると、インデックスを使用しないクエリも、スロークエリログに記録される。このオプションは MySQL 4.1 で導入された。 「4.10.5 スロークエリログ」 節 参照 。

--log-short-format
ログファイル（更新ログ、バイナリ更新ログ、スロークエリログなど、有効化されているすべてのログ）に記録される情報が少なくなる。たとえば、クエリのユーザ名とタイムスタンプが記録されなくなる。このオプションは MySQL 4.1 で導入。

--log-slow-queries[=file]
実行時間が long_query_time 秒を超えたクエリをすべてログファイルに記録する。 注意: 記録されるデフォルトの情報量は MySQL 4.1 で変更された。詳細については、--log-long-format オプションおよび --log-long-format オプションの説明を参照のこと。 「4.10.5 スロークエリログ」 節 参照 。

--log-update[=file]
指定がなければ、更新を file.# に記録する。# は一意の番号。 「4.10.3 更新ログ」 節 参照 。 更新ログは MySQL 5.0 で廃止されるので、代わりにバイナリログ（--log-bin）を使用すること。 「4.10.4 バイナリログ」 節 参照 。 バージョン 5.0 からは、--log-update を使用すると単にバイナリログが有効になる。

--low-priority-updates
テーブル編集操作（INSERT、DELETE、UPDATE）の優先順位が選択よりも低くなる。{INSERT | REPLACE | UPDATE | DELETE} LOW_PRIORITY ... を使用して 1 つのクエリだけ優先順位を低くしたり、SET LOW_PRIORITY_UPDATES=1 を使用して 1 つのスレッド内での優先順位を変更することもできる。 「5.3.2 テーブルロック関連の問題」 節 参照 。

--memlock
メモリ内の mysqld プロセスをロックする。これは、使用しているシステムが mlockall() システムコールをサポートしている場合（Solaris など）のみで使用可能。オペレーティングシステムが原因で mysqld のスワップが発生するという問題がある場合、その解決に役立つ。 注意: このオプションを使用するには、サーバを root として起動することが必要になるが、これはセキュリティ上好ましくない。

--myisam-recover [=option[,option...]]
オプションは、DEFAULT、BACKUP、FORCE、および QUICK の任意の組み合わせ。このオプションを無効にするには、これを明示的に "" に設定する。このオプションを使用すると、mysqld はテーブルを開くときに、テーブルにクラッシュのマークが付いていないか、つまりテーブルが正しく閉じられているかどうかをチェックする （最後のオプションは、--skip-external-locking を使用している場合だけ有効）。テーブルにクラッシュマークが付いていた場合、mysqld はテーブルをチェックする。テーブルが破損していた場合、mysqld は修復を試みる。

以下のオプションにより、修復方法が決定される。

オプション 説明
DEFAULT --myisam-recover でどのオプションも指定しないのと同じ。
BACKUP 修復時にデータテーブルが変更された場合、`table_name.MYD' データファイルのバックアップを `table_name-datetime.BAK' として保存する。
FORCE .MYD ファイルから複数のレコードが失われる場合でも修復を実行する。
QUICK 削除ブロックがない場合、テーブル内のレコードをチェックしない。

テーブルを自動的に修復する前に、MySQL はそのことをエラーログに追加する。ユーザの介入なしにほとんどすべての問題をリカバリできるようにするには、オプション BACKUP,FORCE を使用する。これにより、いくつかのレコードが削除される場合でもテーブルの修復が行われるが、古いデータファイルがバックアップとして残るので後で調べることができる。

--new
バージョン 4.0.12 から使用可能となったオプション。--new オプションを使用すると、特定の局面でサーバを 4.1 のように動作させることができ、簡単に 4.0 から 4.1 にアップグレードできる。

--pid-file=path
mysqld_safe によって使用される PID ファイルのパス。

-P, --port=...
TCP/IP 接続をリッスンするポート番号。

-o, --old-protocol
非常に古いクライアントとの互換性のために 3.20 プロトコルを使用する。 「2.5.5 バージョン 3.20 から 3.21 へのアップグレード」 節 参照 。

--one-thread
1 スレッドのみ使用する（Linux でのデバッグ用）。 このオプションは、サーバのデバッグが有効になっている場合のみ使用可能。 「E.1 MySQL サーバのデバッグ」 節 参照 。

--open-files-limit=
mysqld で使用可能なファイル記述子の数を変更できる。 これが設定されていないか、または 0 に設定されている場合、mysqld は、setrlimit() で使用する値を使用してファイル記述子を予約する。この値が 0 の場合、mysqld は max_connections*5 または max_connections + table_cache*2 のいずれか大きい値をファイル数として予約する。mysqld で ' Too many open files ' のエラーが出る場合、この値を大きくする。

-O, --set-variable=name=value
変数に値を設定する。--help により変数一覧を表示できる。すべての変数の詳細については、このマニュアルの SHOW VARIABLES セクションを参照のこと。 「4.6.8.4 SHOW VARIABLES」 節 参照 。 これら変数を最適化する方法については、「サーバパラメータのチューニング」セクションを参照のこと。 注意: --set-variable=変数名=値 および -O 変数名=値 構文は、MySQL 4.0 で廃止。代わりに --変数名=値 を使用すること。 「5.5.2 サーバパラメータのチューニング」 節 参照 。

MySQL 4.0.2 では変数を --変数名=値 で直接設定できるので、set-variable は必要なくなった。

SET で設定可能なスタートアップオプションの最大値を制限するには、--maximum-variable-name コマンドラインオプションを使用して定義する。 「5.5.6 SET 構文」 節 参照 。

注意: 変数に値を設定すると、その値が設定可能範囲に収まるように、また使用アルゴリズムに合うように自動的に変数値が修正される。

--safe-mode
いくつかの最適化ステージをスキップする。

--safe-show-database
このオプションを使用して SHOW DATABASES コマンドを実行すると、そのユーザが何らかの権限を持っているデータベースのみが戻り値として返る。 バージョン 4.0.2 からすべてのユーザが SHOW DATABASES 権限を持つようになったので、このオプションは廃止され、何もしない（このオプションはデフォルトで有効）。 「4.4.1 GRANT および REVOKE の構文」 節 参照 。

--safe-user-create
これを有効にした場合、ユーザに mysql.user テーブルあるいはそのテーブル内のカラムへの INSERT 権限がなければ、そのユーザは GRANT コマンドを使用して新規ユーザを作成できない。

--skip-bdb
BDB テーブルの使用を無効にする。メモリの節約および演算処理のスピードアップに役立つ。

--skip-concurrent-insert
MyISAM テーブルで SELECT と INSERT を同時に実行できなくする（これは、この機能にバグがあると思われる場合だけ使用すること）。

--skip-delay-key-write
MySQL 4.0.3 では、代わりに --delay-key-write=OFF を使用する。 すべてのテーブルの DELAY_KEY_WRITE オプションを無視する。 「5.5.2 サーバパラメータのチューニング」 節 参照 。

--skip-grant-tables
サーバが一切の権限システムを使用しないようにする。これによりすべての人が、すべてのデータベースにフルアクセスできるようになる（実行中のサーバに権限テーブルを再び使用させるには、mysqladmin flush-privileges または mysqladmin reload を実行する）。

--skip-host-cache
IP への名前解決に、ホスト名キャッシュを使用せず、接続ごとに DNS サーバに対しクエリを発行する。 「5.5.5 MySQL の DNS の使用」 節 参照 。

--skip-innodb
Innodb テーブルの使用を無効にする。メモリとディスク領域の節約および演算処理のスピードアップに役立つ。

--skip-external-locking（以前は --skip-locking）
システムロックを使用しない。isamchk または myisamchk を使用するには、サーバをシャットダウンする必要がある。 「1.2.3 MySQL の安定性」 節 参照 。 注意: MySQL バージョン 3.23 では、REPAIR および CHECK を使用して MyISAM テーブルを修復したりチェックすることができる。

--skip-name-resolve
ホスト名を解決しない。権限テーブルの Host カラムの値がすべて IP アドレスまたは localhost であることが必要である。 「5.5.5 MySQL の DNS の使用」 節 参照 。

--skip-networking
TCP ポートを一切リッスンしない。mysqld とのやり取りはすべて、名前付きパイプまたは Unix ソケットを介して行う必要がある。ローカルからの接続要求のみが許可されているシステムにおいて、特にこのオプションが推奨される。 「5.5.5 MySQL の DNS の使用」 節 参照 。

--skip-new
新しくて間違っている可能性のあるルーチンを使用しない。

--skip-symlink
4.0.13 で廃止。代わりに --skip-symbolic-links を使用すること。

--symbolic-links, --skip-symbolic-links
シンボリックリンクのサポートを有効または無効にする。このオプションは、Windows と Unix では効果が異なる。

Windows でシンボリックリンクを有効にすると、実際のディレクトリへのパスが含まれる directory.sym ファイルの作成により、データベースディレクトリへのシンボリックリンクを作成できるようになる。 「5.6.1.3 Windows 上のデータベースに対するシンボリックリンクの使用」 節 参照 。

Unix でシンボリックリンクを有効にすると、CREATE TABLE ステートメントの INDEX DIRECTORY オプションまたは DATA DIRECTORY オプションで MyISAM のインデックスファイルまたはデータファイルを別ディレクトリにリンクできるようになる。テーブルを削除したり名前を変更すると、そのシンボリックリンクがポイントするファイルも削除または名前変更される。

--skip-safemalloc
MySQL を --with-debug=full でコンフィギャしていれば、すべてのプログラムが、メモリの割り当て時と解放時に必ずメモリのオーバーランをチェックする。このチェックには時間がかかるため、このチェックを行わないで済むサーバに対しては、--skip-safemalloc オプションによりチェックをスキップできる。

--skip-show-database
ユーザが SHOW DATABASES 権限を持っていない場合に、SHOW DATABASES コマンドを無効にする。

--skip-stack-trace
スタックトレースを書き込まない。このオプションは、デバッガで mysqld を実行するときに役立つ。システムによっては、コアファイルを取得するためにこのオプションの使用が必要な場合もある。 「E.1 MySQL サーバのデバッグ」 節 参照 。

--skip-thread-priority
応答時間を短くするため、スレッド優先度の使用を無効にする。

--socket=path
Unix では、ローカル接続に使用するソケットファイル（デフォルトでは `/tmp/mysql.sock'）。 Windows では、名前付きパイプを使用するローカル接続用パイプ名（デフォルトでは MySQL）。

--sql-mode=value[,value[,value...]]
オプション値として、次の任意の組み合わせを設定できる。 REAL_AS_FLOAT、PIPES_AS_CONCAT、ANSI_QUOTES、IGNORE_SPACE、ONLY_FULL_GROUP_BY、NO_UNSIGNED_SUBTRACTION、NO_AUTO_VALUE_ON_ZERO、NO_TABLE_OPTIONS、NO_FIELD_OPTIONS、NO_KEY_OPTIONS、NO_DIR_IN_CREATE、MYSQL323、MYSQL40、DB2、MAXDB、MSSQL、ORACLE、POSTGRESQL、および ANSI。 リセットするには、値を空白にする（--sql-mode=""）。

NO_AUTO_VALUE_ON_ZERO は、AUTO_INCREMENT カラムの処理に影響を与える。通常、NULL または 0 のいずれかをカラムに挿入することにより、カラムの次のシーケンス番号を生成する。 NO_AUTO_VALUE_ON_ZERO を指定すると、0 のこの働きが抑制されるため、NULL だけが次のシーケンス番号を生成することになる。このモードは、0 がテーブルの AUTO_INCREMENT カラムに保存されている場合に役に立つ（これは推奨されている方法ではないが）。たとえば、mysqldump でテーブルをダンプしてから再読み込みした場合、MySQL は通常、0 値に遭遇したときに新規シーケンス番号を生成するため、ダンプされたテーブルと再読み込みしたテーブルの内容が異なる結果になる。この場合、ダンプしたファイルを再読み込みする前に NO_AUTO_VALUE_ON_ZERO を有効にするとこの問題が解決する（このオプションが使用可能になった MySQL 4.1.1 以降、mysqldump によるダンプ出力には、自動的に NO_AUTO_VALUE_ON_ZERO を有効にするためのステートメントが含まれている）。

他のサーバとの互換性のために使用するオプション値もある。 これらを指定することにより、SHOW CREATE TABLE の実行結果から、以前のバージョンの MySQL または他のデータベースサーバが理解できない出力が除外される。 これらのオプション値を使用すると、CREATE TABLE ステートメントの他のサーバへの移植性が高まる。

mysqldump は SHOW CREATE TABLE を使用して、ダンプ出力に含むテーブル作成ステートメントを取得するため、これらのオプションは mysqldump の出力にも影響する。

オプション値のいくつかは、値のセットまたはグループの略称なので、影響は複雑になる。 たとえば、--sql-mode=ANSI（または --ansi）オプションを使用して、サーバに ANSI モードで実行するように命令できる。これは以下のコマンドラインオプションを両方指定するのと同じ。

 
--sql-mode=REAL_AS_FLOAT,PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE,ONLY_FULL_GROUP_BY
--transaction-isolation=SERIALIZABLE

注意: この方法で ANSI モードを指定すると、トランザクション分離レベルを設定することにもなる。 ANSI モードでのサーバの実行については、 「1.8.2 ANSI モードでの MySQL の実行」 を参照のこと。

他の "グループ" 値は、DB2、MAXDB、MSSQL、ORACLE、および POSTGRESQL。 これらのいずれの値を指定しても、PIPES_AS_CONCAT、ANSI_QUOTES、IGNORE_SPACE、NO_TABLE_OPTIONS、NO_FIELD_OPTIONS、および NO_KEY_OPTIONS 値が有効になる。

--sql-mode オプションは MySQL 3.23.41 で追加された。 NO_UNSIGNED_SUBTRACTION 値は 4.0.0 で追加された。 NO_DIR_IN_CREATE は 4.0.15 で追加された。 NO_AUTO_VALUE_ON_ZERO、NO_TABLE_OPTIONS、NO_FIELD_OPTIONS、NO_KEY_OPTIONS、MYSQL323、MYSQL40、DB2、MAXDB、MSSQL、ORACLE、POSTGRESQL、および ANSI は 4.1.1 で追加された。

--temp-pool
このオプションを使用すると、サーバによって作成される大部分のテンポラリファイルが、それぞれ一意の名前ではなく、小さな名前のセットを使用する。これは、多くの新規ファイルが異なる名前で作成され、それを Linux カーネルが処理する問題を回避するためである。Linux では、メモリがディスクキャッシュではなく、ディレクトリエントリキャッシュに割り当てられるため、以前の動作ではメモリの "リーク" が発生しやすい。

--transaction-isolation={ READ-UNCOMMITTED | READ-COMMITTED | REPEATABLE-READ | SERIALIZABLE }
デフォルトのトランザクション分離レベルを設定する。 「6.7.6 SET TRANSACTION 構文」 節 参照 。

-t, --tmpdir=path
テンポラリファイルの作成に使用されるディレクトリのパス。テンポラリファイルを保存するには小さすぎるパーティション上にデフォルトの /tmp ディレクトリがある場合、このオプションが役に立つ。 MySQL 4.1 以降、複数のパスの指定が可能になっている。これらのパスはラウンドロビン方式で使用される。Unix ではコロン（`:'）を、Windows ではセミコロン（`;'）を使用してパスを区切る。 メモリベースのファイルシステムを指すように tmpdir を設定することは可能。ただし、MySQL サーバがスレーブの場合はできない。スレーブの場合、マシンがリブートしてもテンポラリテーブルのレプリケーションまたは LOAD DATA INFILE のレプリケーション処理を続行するためのテンポラリファイルが必要となる。そのため、マシンのリブートで消去されるメモリベースの tmpdir は適しない。ディスクベースの tmpdir が必要。

-u, --user={user_name | user_id}
mysqld サーバを、ユーザ名 user_name またはユーザ ID user_id を持つユーザとして実行する （ここでの "ユーザ" は、権限テーブルにリストされた MySQL ユーザではなく、システムログインアカウントを指す）。

このオプションは、mysqld を root アカウントで起動する場合、必須である。 起動シーケンス中にサーバがそのユーザ ID を変更し、root ではなく、その特定のユーザとして実行する。 「4.3.2 MySQL のクラッカー対策」 節 参照 。

MySQL 3.23.56 および 4.0.12 以降では、 ユーザが --user=root オプションを `my.cnf' ファイルに追加するという（結果、サーバは root として稼動）セキュリティホールを回避するため、mysqld は指定された最初の --user オプションだけを使用し、複数の --user オプションがあった場合は警告を出力する。`/etc/my.cnf' および `datadir/my.cnf' 内のオプションは、コマンドラインオプションの前に処理されるため、--user オプションを `/etc/my.cnf' に含めて root 以外の値を指定することを推奨する。`/etc/my.cnf' 内のオプションは他の --user オプションより先に検出され、サーバは確実に root 以外のユーザとして実行され、他の --user オプションが検出されると警告が出力される。

-V, --version
バージョン情報を表示して終了する。

-W, --log-warnings
Aborted connection... などの警告を `.err' ファイルに出力する。レプリケーションを使用する場合は、このオプションを有効にすることを推奨する（ネットワークエラーや再接続に関するメッセージなど、現在何が起こっているかについての情報をより多く取得できる）。 「A.2.10 通信エラー/Aborted connection」 節 参照 。

このオプションは以前の --warnings。

実行中のサーバに対して、ほとんどの値を SET コマンドで変更できます。 「5.5.6 SET 構文」 節 参照 。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.1.2 `my.cnf' オプション設定ファイル

MySQL ではバージョン 3.22 以降、サーバとクライアントのデフォルトスタートアップオプションをオプション設定ファイルから読み取ることができるようになっています。

Windows では、MySQL はデフォルトオプションを以下のファイルから読み取ります。

ファイル名 用途
windows-directory\my.ini グローバルオプション
C:\my.cnf グローバルオプション

windows-directory は Windows ディレクトリの保存場所です。

Unix では、MySQL はデフォルトオプションを以下のファイルから読み取ります。

ファイル名 用途
/etc/my.cnf グローバルオプション
DATADIR/my.cnf サーバ固有オプション
defaults-extra-file --defaults-extra-file=path で指定されたファイル
~/.my.cnf ユーザ固有オプション

DATADIR は MySQL データディレクトリです（通常、バイナリインストールの場合は `/usr/local/mysql/data'、ソースインストールの場合は `/usr/local/var'）。 注意: これは、コンフィギャ時に指定されたディレクトリです。mysqld 起動時に --datadir で指定したディレクトリではありません。サーバはコマンドラインの引数を処理する前にオプション設定ファイルを探すため、--datadir による指定は、サーバがオプション設定ファイルを探す場所に影響しません。

注意: Windows では、オプション設定ファイル内のすべてのパスを `\' ではなく、`/' で指定してください。`\' は MySQL の エスケープ文字であるため、`\' を使用する場合は 2 回指定する必要があります。

MySQL は、オプション設定ファイルを上記の順序で読み取ろうとします。複数のオプション設定ファイルが存在する場合、後で読み取られたファイルに指定されているオプションの方が、先に読み取られたファイル内の同一オプションより優先されます。コマンドラインで指定されたオプションは、オプション設定ファイルで指定されたオプションよりも優先されます。オプションによっては、環境変数を使用して指定できるものもあります。 コマンドラインまたはオプション設定ファイルで指定されたオプションの方が、環境変数値よりも優先されます。 「F. 環境変数」 節 参照 。

オプション設定ファイルをサポートするプログラムは、mysql、mysqladmin、mysqld、mysqld_safe、mysql.server、mysqldump、mysqlimport、mysqlshow、mysqlcheck、myisamchk、および myisampack です。

バージョン 4.0.2 より、loose プリフィックスをコマンドラインオプション（または my.cnf のオプション）に使用できます。オプションの前に loose を付けると、オプションが未知の場合でも、それを読み取ったプログラムはエラー終了せず、以下の警告を出力します。

 
shell> mysql --loose-no-such-option

MySQL プログラム実行時にコマンドラインで指定できる長いオプションは、オプション設定ファイルで指定できます（ダッシュ2つを前に付けない）。使用可能なオプションの一覧を表示するには、--help オプション付きでそのプログラムを実行してください。

オプション設定ファイルには、以下の形式の行を含めることができます。

#comment
コメント行は、`#' または `;' で始める。MySQL 4.0.14 より、コメントを行の途中からでも開始できるようになった。空白行は無視される。

[group]
group は、オプションを設定するプログラムまたはグループの名前。グループ行の後の option行または set-variable 行はすべてそのグループに適用される。これは、オプション設定ファイルの最後、または他のグループ行が指定されるまで有効。

option
これは、コマンドラインの --option と同等。

option=value
これは、コマンドラインの --option=value と同等。注意: オプションの引数にコメント文字が含まれる場合、引数を二重引用符で囲む必要がある。

set-variable = name=value
これは、コマンドラインの --set-variable=name=value と同等。 注意: --set-variable は MySQL 4.0 で廃止された。MySQL 4.0 では、プログラム変数名をオプション名として使用できる。コマンドラインでは、--name=value を使用する。オプション設定ファイルでは、name=value を使用する。

[client] グループにより、すべての MySQL クライアント（mysqld ではなく）に適用されるオプションを指定できます。これは、サーバに接続する際に使用するパスワードを指定するための理想的なグループです（ただし、管理者以外のユーザがオプション設定ファイルを読み書きできないようにしてください）。

特定のバージョンの mysqld サーバだけが読み取れるオプションを作成するには、[mysqld-4.0]、[mysqld-4.1] などを使用します。

 
[mysqld-4.0]
new

上記の new オプションは、MySQL サーババージョン 4.0.x でのみ使用されます。

注意: オプションおよび値に対して、その前後にある空白は自動的に削除されます。エスケープシーケンス `\b'、`\t'、`\n'、`\r'、`\\'、および `\s' を値文字列に使用することができます（`\s' == blank）。

次に、一般的なグローバルオプション設定ファイルの例を示します。

 
[client]
port=3306
socket=/tmp/mysql.sock

[mysqld]
port=3306
socket=/tmp/mysql.sock
set-variable = key_buffer_size=16M
set-variable = max_allowed_packet=1M

[mysqldump]
quick

次に、一般的なユーザオプション設定ファイルの例を示します。

 
[client]
# 以下のパスワードは、標準の MySQL クライアント全てに使用されます
password="my_password"

[mysql]
no-auto-rehash
set-variable = connect_timeout=2

[mysqlhotcopy]
interactive-timeout

ソースディストリビューションがあれば、`my-xxxx.cnf' という名前の設定ファイルのサンプルが `support-files' ディレクトリに含まれています。 バイナリディストリビューションの場合は、`DIR/support-files' ディレクトリにあります。ここで、DIR は MySQL インストールディレクトリのパスです（通常、`C:\mysql' または `/usr/local/mysql'）。現在、小、中、大、および特大システム用のサンプル設定ファイルが用意されています。`my-xxxx.cnf' を自分のホームディレクトリにコピーして、名前を `.my.cnf' に変更し、このファイルを使用してみてください。

オプション設定ファイルをサポートする MySQL プログラムはすべて、以下のオプションをサポートします。

オプション 説明
--no-defaults オプション設定ファイルを一切読み取らない。
--print-defaults プログラム名と、取得するすべてのオプションを出力する。
--defaults-file=full-path-to-default-file 指定された設定ファイルだけを使用する。
--defaults-extra-file=full-path-to-default-file グローバル設定ファイルを読み取った後、ユーザ設定ファイルの前にこの設定ファイルを読み取る。

注意: これらのオプションは、コマンド行の最初に置く必要があります。ただし、--print-defaults だけは、--defaults-file または --defaults-extra-file の直後に置くことができます。

開発者向け注意: オプション設定ファイルの処理としては、コマンドライン引数を処理する前に、オプション設定ファイル内のすべての合致するオプション（該当グループのオプション）が処理されるようになっています。複数回指定されているオプションの最後のインスタンスを使用するプログラムにとっては、この処理で問題ありません。複数回指定されているオプションを処理するが、オプション設定ファイルは読み取らない旧式のプログラムについては、2 行追加するだけでその機能を装備できます。 その方法については、標準 MySQL クライアントのいずれかのソースコードを確認してください。

シェルスクリプトで、my_print_defaults コマンドを使用してオプション設定ファイルを解析することができます。以下の例は、[client] グループと [mysql] グループに属すオプションの表示要求があった場合に、my_print_defaults が生成する可能性のある出力です。

 
shell> my_print_defaults client mysql
--port=3306
--socket=/tmp/mysql.sock
--no-auto-rehash

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.2 同じマシン上で複数の MySQL サーバを実行する

4.2.1 Windows 上で複数のサーバを実行する   
4.2.2 Unix 上で複数のサーバを実行する   
4.2.3 複数サーバ環境でクライアントプログラムを使用する   

場合によっては、同じマシン上で複数の mysqld サーバを実行することが必要になります。たとえば、既存の稼働環境のままにして、新しい MySQL リリースをテストしたい場合が考えられます。 また、ユーザごとに異なる mysqld サーバへのアクセス権を与える場合などもあります（たとえば、顧客ごとに独立した MySQL インストールを提供するインターネットサービスプロバイダなど）。

単一のマシン上で複数のサーバを実行するには、いくつかのパラメータでサーバ固有の値を設定する必要があります。これらはコマンドラインまたはオプション設定ファイルで設定できます。 「4.1.1 mysqld コマンドラインオプション」 および 「4.1.2 `my.cnf' オプション設定ファイル」 を参照してください。

少なくとも以下のオプションはサーバごとに異なります。

--port は、TCP/IP 接続のポート番号を制御します。 --socket は、Unix ではソケットファイルパスを、Windows では名前付きパイプの名前を制御します（名前付きパイプ接続をサポートしているサーバに対してのみ、Windows 上で一意のパイプ名を指定する必要があります）。 --shared-memory-base-name は、Windows サーバが使用する共有メモリ名を指定します。これにより、クライアントはその共有メモリを介して接続できるようになります。 --pid-file は、Unix サーバがプロセス ID を書き込むファイルの名前を示します。

以下のオプションを使用する場合、サーバごとに異なる値を設定する必要があります。

パフォーマンスを高めるには、以下のオプションをサーバごとに個別に設定し、負荷を複数のディスクに分散します。

複数のテンポラリディレクトリを上記のように設定し、どの MySQL サーバにどのテンポラリファイルが属するのかわかりやすくしておくことを推奨します。

一般的に、データディレクトリについても、各サーバが異なるディレクトリを使用するようにします。これは --datadir=path オプションで指定します。

警告: 2 つのサーバから同じデータベースのデータを更新しないようにしてください。使用しているオペレーティングシステムが障害からの保護をおこなうようなシステムロックをサポートしていない場合、予期しない事態が発生する可能性があります。また、複数のサーバが同じデータディレクトリを使用し、ログが有効になっている場合、適切なオプションを使用して各サーバに異なるログファイル名を指定する必要があります。そうしないと、サーバは同じファイルにログしてしまいます。

サーバ間でのデータディレクトリ共有に関するこの警告は、NFS 環境にも当てはまります。NFS 環境で複数の MySQL サーバに同じデータディレクトリへのアクセスを認めることは避けてください。

簡単な方法を選択してください。NFS で複数のサーバにデータディレクトリを共有させるアイデアは良いアイデアではありません。 また、複数の CPU を持つ 1 台のコンピュータを用意し、スレッドを効率的に処理するオペレーティングシステムを使用することを推奨します。

複数の MySQL インストールを異なるロケーションで行う場合、--basedir=path オプションを使用して各サーバに対してベースディレクトリを指定し、各サーバがそれぞれ別のデータディレクトリ、ログファイル、および PID ファイルを使用するようにできます（これらの値のデフォルトは、ベースディレクトリに相対して決定されます）。その場合、他に指定する必要があるオプションは --socket と --port だけです。たとえば、`.tar' ファイルバイナリディストリビューションを使用して MySQL の複数のバージョンをインストールするとします。これらは別々のロケーションにインストールされるので、対応するベースディレクトリ以下で ./bin/mysqld_safe コマンドを使用して、各インストールのサーバを起動することができます。 mysqld_safe が、mysqld に渡す適切な --basedir オプションを特定するので、--socket オプションと --port オプションを mysqld_safe に設定するだけで済みます。

以下のセクションで説明するように、環境変数の設定または適切なコマンドラインオプションの指定により、追加サーバを起動することが可能です。ただし、より永続的に複数のサーバを実行する必要がある場合には、オプション設定ファイルを使用して各サーバ固有のオプション値を指定する方法が便利です。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.2.1 Windows 上で複数のサーバを実行する

適切なパラメータを使用し、コマンドラインからサーバを手動で起動することにより、Windows 上で複数のサーバを実行することができます。Windows NT ベースのシステムでは、複数のサーバを Windows サービスとしてインストールし、Windows サービスとして実行する方法もあります。コマンドラインから、またはサービスとして MySQL サーバを実行する方法についての一般的な説明は、 「2.6.1 Windows の注意事項」 に記載されています。このセクションでは、データディレクトリなど、サーバ固有であることが必要なスタートアップオプション値をサーバごとに設定してサーバを起動する方法について説明します（これらのオプションについては、 「4.2 同じマシン上で複数の MySQL サーバを実行する」 を参照してください）。

4.2.1.1 コマンドラインから複数の Windows サーバを起動する   
4.2.1.2 複数の Windows サーバをサービスとして起動する   

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.2.1.1 コマンドラインから複数の Windows サーバを起動する

コマンドラインから手動で複数のサーバを起動するには、コマンドラインまたはオプション設定ファイルで必要なオプションを指定します。オプション設定ファイルでオプションを設定する方が便利ですが、各サーバに独自のオプションセットを確実に設定する必要があります。これを行うには各サーバ用のオプション設定ファイルを作成し、サーバ起動時に --defaults-file を使用してそのサーバにファイル名を指定します。

たとえば、mysqld を、データディレクトリ `C:\mydata1' を使用してポート 3307 で実行し、mysqld-max を、データディレクトリ `C:\mydata2' を使用してポート 3308 で実行するとします。このためには、2 つのオプション設定ファイルを作成します。たとえば、以下のような `C:\my-opts1.cnf' ファイルを作成します。

 
[mysqld]
datadir = C:/mydata1
port = 3307

次に、以下のような 2 つ目のファイル `C:\my-opts2.cnf' を作成します。

 
[mysqld]
datadir = C:/mydata2
port = 3308

そして、それぞれのオプション設定ファイルを使って各サーバを起動します。

 
shell> mysqld --defaults-file=C:\my-opts1.cnf
shell> mysqld-max --defaults-file=C:\my-opts2.cnf

Windows NT では、サーバがフォアグラウンドで起動するため、2 つのコマンドを別々のコンソールウィンドウで実行する必要があります。

サーバをシャットダウンするには、該当するポート番号に接続する必要があります。

 
shell> mysqladmin --port=3307 shutdown
shell> mysqladmin --port=3308 shutdown

この例のように設定されているサーバは、クライアントに対して TCP/IP 接続を許可します。名前付きパイプ接続も可能にするには、mysqld-nt サーバまたは mysqld-max-nt サーバを使用し、名前付きパイプを有効にするオプションを指定し、その名前を指定します（名前付きパイプ接続をサポートするサーバは、それぞれ固有のパイプ名を使用することが必要です）。たとえば、`C:\my-opts1.cnf' ファイルを以下のように修正します。

 
[mysqld]
datadir = C:/mydata1
port = 3307
enable-named-pipe
socket = mypipe1

そして、サーバを次のように起動します。

 
shell> mysqld-nt --defaults-file=C:\my-opts1.cnf

2 つ目のサーバで使用する `C:\my-opts2.cnf' も同様に修正します。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.2.1.2 複数の Windows サーバをサービスとして起動する

Windows NT ベースのシステムでは、MySQL サーバを Windows サービスとして実行できます。単一の MySQL サービスのインストール、制御、および削除の手順については、 「2.1.1.7 Windows NT、2000、または XP での MySQL の起動」 を参照してください。

MySQL 4.0.2 より、複数のサーバをサービスとしてインストールできるようになっています。 その場合、各サーバが異なるサービス名を使用することが必要です。また、サーバごとに一意であることが必要なその他のパラメータにも注意が必要です。

以下の手順は、`C:\mysql-4.0.8' および `C:\mysql-4.0.17' にインストールされた 2 つの異なる MySQL バージョンから mysqld-nt サーバを実行する場合を想定しています（たとえば、本稼働サーバとして 4.0.8 を実行しているときに、アップグレード前に 4.0.17 をテストする場合など）。

--install オプションで MySQL サービスをインストールする場合、以下の原則が当てはまります。

これらの原則は、--install-manual オプションを使用してサーバをインストールした場合にも当てはまります。

以上の情報に基づいて、複数のサービスをセットアップする方法はいくつかあります。 次に、いくつかの例を示します。いずれを試す場合でも、最初に既存の MySQL サービスをシャットダウンして削除しておくことが必要です。

複数のサービスを削除するには、mysqld --remove を使用して 1 つずつ削除します。削除するサービスがデフォルト名でない場合は、--remove オプションの後にサービス名を指定します。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.2.2 Unix 上で複数のサーバを実行する

複数のサーバを Unix 上で実行する最も簡単な方法は、異なる TCP/IP ポートとソケットファイルを使用するようにしてサーバをコンパイルし、それぞれが別のネットワークインタフェースで接続するようにすることです。また、各インストールを別々のベースディレクトリでコンパイルすることにより、データディレクトリ、ログファイル、および PID ファイルの場所をサーバ別にすることができます。

既存サーバがデフォルトのポート番号とソケットファイルでコンフィギャされているとします。新しいサーバを別のパラメータでコンフィギャするには、以下のように configure コマンドを使用します。

 
shell> ./configure --with-tcp-port=port_number \
             --with-unix-socket-path=file_name \
             --prefix=/usr/local/mysql-4.0.17

ここで、port_number と file_name に、デフォルト以外のポート番号とソケットファイルのパス名を指定します。および、--prefix の値も、既存の MySQL インストールの場所とは別のインストールディレクトリを指定します。

MySQL サーバが特定のポート番号をリッスンしている場合、以下のコマンドを使用して、ベースディレクトリやソケット名など、重要な変数の値を確認できます。

 
shell> mysqladmin --host=host_name --port=port_number variables

このコマンドで表示される情報により、追加サーバを設定するときにどのオプション値を使用してはいけないかがわかります。

注意: "localhost" をホスト名として指定すると、mysqladmin は TCP/IP ではなく、Unix ソケット接続をデフォルト使用します。 MySQL 4.1 では、--protocol={TCP | SOCKET | PIPE | MEMORY} オプションを使用して、使用する接続プロトコルを明示的に指定できます。

別のソケットファイルおよび TCP/IP ポート番号で起動するために、新たに MySQL サーバをコンパイルする必要はありません。実行時に値を指定することも可能です。これを行う 1 つの方法として、コマンドラインオプションの使用があります。

 
shell> /path/to/mysqld_safe --socket=file_name --port=port_number

2 番目のサーバに別のデータベースディレクトリを使用するため、--datadir=path オプションを mysqld_safe に渡します。

同様の効果を得る別の方法として、環境変数を使用してソケット名とポート番号を設定することもできます。

 
shell> MYSQL_UNIX_PORT=/tmp/mysqld-new.sock
shell> MYSQL_TCP_PORT=3307
shell> export MYSQL_UNIX_PORT MYSQL_TCP_PORT
shell> scripts/mysql_install_db
shell> bin/mysqld_safe &

この方法を使用すると、テスト用に 2 つ目のサーバをすばやく起動できます。この方法の長所は、上記のシェルから呼び出したどのクライアントプログラムにもこの環境変数が適用される点です。そのため、これらのクライアントの接続は自動的に 2 つ目のサーバにダイレクトされます。

「F. 環境変数」 に、mysqld を制御する他の環境変数の一覧が記載されています。

自動サーバ実行では、ブート時に実行されるスタートアップスクリプトにより、サーバごとに以下のコマンドが 1 回ずつ実行される必要があります。その際、各コマンドに対して適切なオプション設定ファイルのパスを設定します。

 
mysqld_safe --defaults-file=path-to-option-file

各オプション設定ファイルには、特定のサーバに固有のオプション値が含まれていることが必要です。

Unix では、mysqld_multi スクリプトを使用して複数のサーバを開始することもできます。 「4.8.3 mysqld_multi（複数の MySQL サーバを管理するプログラム）」 節 参照 。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.2.3 複数サーバ環境でクライアントプログラムを使用する

クライアントにコンパイルされたネットワークインタフェース以外のネットワークインタフェースをリッスンしている MySQL サーバにそのクライアントから接続するには、以下のいずれかの方法を実行します。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.3 一般的なセキュリティ関連事項と MySQL アクセス制御システム

MySQL には、非標準ですが、上級のセキュリティおよび権限システムがあります。このセクションでは、その機能について説明します。

4.3.1 一般的なセキュリティガイドライン   
4.3.2 MySQL のクラッカー対策   
4.3.3 セキュリティ関連の mysqld スタートアップオプション   
4.3.4 LOAD DATA LOCAL のセキュリティ関連事項   
4.3.5 権限システムが行うこと   
4.3.6 権限システムはどのように機能するか   
4.3.7 MySQL が提供する権限   
4.3.8 MySQL サーバへの接続   
4.3.9 アクセス制御の段階 1: 接続確認   
4.3.10 アクセス制御の段階 2: 要求確認   
4.3.11 MySQL 4.1 のパスワードハッシュ   
4.3.12 Access denied エラーの原因   

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.3.1 一般的なセキュリティガイドライン

インターネットに接続されたコンピュータで MySQL を使用するユーザはすべて、このセクションを読んで、頻発しているセキュリティ侵害を回避するようにしてください。

盗聴傍受、改ざん、再生、サービス妨害など、あらゆるタイプの攻撃に対して、MySQL サーバだけでなく、サーバホスト全体を、最大限の努力をもって保護することが必要です。ここでは、可用性および耐障害性のすべてについてはカバーしていません。

MySQL では、すべての接続、クエリなど、ユーザが実行する可能性のある操作に対して、そのセキュリティを、アクセス制御リスト（ACL）をベースにして保護しています。MySQL クライアントとサーバ間の SSL 暗号化接続もサポートしています。ここで説明する概念の多くは、MySQL 固有ではありません。ほとんどすべてのアプリケーションに当てはまります。

MySQL を実行する際には、可能な限り以下のガイドラインに従ってください。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.3.2 MySQL のクラッカー対策

MySQL サーバに接続するとき、通常はパスワードを使用します。パスワードはテキスト形式で送信されるわけではありませんが、暗号化アルゴリズムはそれほど強力なものではありません。クライアントとサーバ間のトラフィックを盗聴できれば、クラッカーは少しの努力でパスワードを探り当てることができます。クライアントとサーバ間の接続が信頼されていないネットワークを通る場合には、SSH トンネルを使用して通信を暗号化してください。

その他の情報はすべてテキストとして転送されるので、その接続を見ることができる人はだれでもそれらの情報を読むことができます。これに不安を感じる場合は、圧縮プロトコル（MySQL バージョン 3.22 以降）を使用してトラフィックの解読をより困難にすることができます。セキュリティをさらに高めるには、ssh を使用してください。オープンソース の ssh クライアントは http://www.openssh.org/ に、商用 ssh クライアントは http://www.ssh.com/ にあります。これを使用すると、MySQL サーバと MySQL クライアント間で暗号化 TCP/IP 接続を利用できます。

MySQL 4.0 を使用している場合、内部 OpenSSL サポートも利用できます。 「4.4.10 安全な接続の使用」 節 参照 。

MySQL システムのセキュリティを確保するためには、以下の事項を強く推奨します。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.3.3 セキュリティ関連の mysqld スタートアップオプション

セキュリティに影響する mysqld オプションは以下のとおりです。

--local-infile[=(0|1)]
--local-infile=0 を使用すると、LOAD DATA LOCAL INFILE を使用できなくなる。

--safe-show-database
このオプションを使用すると、SHOW DATABASES コマンドで、そのユーザが何らかの権限を持っているデータベースのみが返される。 現在は、SHOW DATABASES 権限が存在するため、バージョン 4.0.2 以降、このオプションは廃止されており、何もしない（デフォルトで有効になっている）。 「4.4.1 GRANT および REVOKE の構文」 節 参照 。

--safe-user-create
このオプションが有効になっている場合、ユーザに mysql.user テーブルへの INSERT 権限がなければ、そのユーザは GRANT コマンドを使用して新規ユーザを作成できない。ユーザが事前設定された権限で新規ユーザを作成できるようにするには、そのユーザに以下の権限を設定することが必要である。

 
mysql> GRANT INSERT(user) ON mysql.user TO 'user'@'hostname';

これで、ユーザは権限カラムを直接変更できないが、GRANT コマンドを使用して他のユーザに権限を与えることができるようになる。

--skip-grant-tables
サーバが権限システムをまったく使用しないようにする。これによりすべての人が、すべてのデータベースにフルアクセスできるようになる。実行中のサーバに権限テーブルを再び使用させるためには、mysqladmin flush-privileges 、 mysqladmin reload または FLUSH PRIVILEGES; を実行すればよい。

--skip-name-resolve
ホスト名を解決しない。権限テーブルの Host カラム値はすべて IP アドレスか localhost でなければならない。

--skip-networking
TCP/IP 経由の接続を認めない。mysqld への接続をすべて Unix ソケットで行う。 このオプションは、3.23.27 より前の MySQL バージョンで MIT-pthreads パッケージを利用しているものには適さない。その当時、Unix ソケットは MIT-pthreads によってサポートされていなかったからである。

--skip-show-database
SHOW DATABASES 権限のないユーザに SHOW DATABASES コマンドの使用を認めない。バージョン 4.0.2 から、このオプションは必要なくなった。現在では、SHOW DATABASES 権限が割り当てられることでコマンドを使用できるようになっている。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.3.4 LOAD DATA LOCAL のセキュリティ関連事項

MySQL 3.23.49 および MySQL 4.0.2（Windows では 4.0.13）で、LOAD DATA LOCAL に関するセキュリティ対策としていくつかの新しいオプションが追加されました。

このコマンドには次のような潜在的な問題が 2 つあります。

ファイルの読み取りがサーバ側から開始されるため、理論的には、改悪した MySQL サーバを作成しておけば、クライアントがテーブルに対してクエリを実行した時に、そのクライアントコンピュータ上に存在する全てのファイル(カレントユーザが読み取り権を持つ)を、改悪した MySQL サーバが読み取れるということになります。

クライアントが Web サーバから接続する Web 環境では、ユーザは LOAD DATA LOCAL を使用して、Web サーバプロセスが読み取りアクセス権を持つどのファイルでも読み取ることができます（ユーザが SQL サーバに対してすべてのコマンドを実行できる場合）。

これには 2 つの解決方法があります。

MySQL を --enable-local-infile でコンフィギャしていなければ、mysql_options(... MYSQL_OPT_LOCAL_INFILE, 0) を呼び出さないクライアントは LOAD DATA LOCAL を使用できません。 「11.1.3.40 mysql_options()」 節 参照 。

mysql コマンドラインクライアントに対しては、--local-infile[=1] オプションで LOAD DATA LOCAL を有効にでき、--local-infile=0 オプションで無効にできます。

デフォルトでは、すべての MySQL クライアントとライブラリが --enable-local-infile でコンパイルされ、MySQL 3.23.48 以前との互換性が保たれるようになっています。

MySQL サーバですべての LOAD DATA LOCAL コマンドを無効にするには、mysqld を --local-infile=0 で開始します。

LOAD DATA LOCAL INFILE がサーバまたはクライアントで無効になっている場合、次のエラーメッセージ（1148）が表示されます。

 
The used command is not allowed with this MySQL version

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.3.5 権限システムが行うこと

MySQL 権限システムは、主に、任意のホストから接続したユーザを認証し、そのユーザを、データベース上に登録されている権限（SELECT、INSERT、UPDATE、DELETE）と関連付けます。

さらに、匿名ユーザを作成し、LOAD DATA INFILE や管理操作機能など MySQL 固有の機能を実行するための権限を設定します。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.3.6 権限システムはどのように機能するか

MySQL 権限システムは、すべてのユーザがそれぞれ許可された操作だけを実行できるようにします。MySQL サーバに接続すると、ユーザの ID は接続元のホストおよび指定したユーザ名によって特定されます。権限システムは、ユーザ ID と行いたい操作に応じて権限を設定します。

MySQL では、ホスト名とユーザ名を使用してユーザを認証します。1 つのユーザ名がインターネット上のどこででも同じユーザを示しているという保証がないためです。たとえば、office.com から接続したユーザ joe は、elsewhere.com から接続した joe と同一人物とは限りません。 MySQL では、同じユーザ名でも異なるホストから接続するユーザ間で区別することにより、このことを処理しています。joe に対して、office.com から接続した場合の権限セットと、elsewhere.com から接続した場合の権限セットを別々に設定できます。

MySQL のアクセス制御には 2 段階があります。

注意: 接続中に権限が変更された場合（ユーザ自身または第三者によって）、必ずしもその変更は次のクエリに反映されません。詳細については、 「4.4.3 権限の変更はいつ反映されるか」 を参照してください。

サーバはアクセス制御の両方の段階で、mysql データベースの user、db、host の各テーブルを使用します。これらの権限テーブルのフィールドを以下に示します。

テーブル名 user db host
スコープフィールド Host Host Host
User Db Db
Password User
権限フィールド Select_priv Select_priv Select_priv
Insert_priv Insert_priv Insert_priv
Update_priv Update_priv Update_priv
Delete_priv Delete_priv Delete_priv
Index_priv Index_priv Index_priv
Alter_priv Alter_priv Alter_priv
Create_priv Create_priv Create_priv
Drop_priv Drop_priv Drop_priv
Grant_priv Grant_priv Grant_priv
References_priv References_priv References_priv
Reload_priv
Shutdown_priv
Process_priv
File_priv
Show_db_priv
Super_priv
Create_tmp_table_priv Create_tmp_table_priv Create_tmp_table_priv
Lock_tables_priv Lock_tables_priv Lock_tables_priv
Execute_priv
Repl_slave_priv
Repl_client_priv
ssl_type
ssl_cypher
x509_issuer
x509_cubject
max_questions
max_updates
max_connections

アクセス制御の 2 段階目（要求確認）で、要求がテーブルに関連するものである場合、サーバがさらに tables_priv テーブルおよび columns_priv テーブルを参照することがあります。これらのテーブルのフィールドを以下に示します。

テーブル名 tables_priv columns_priv
スコープフィールド Host Host
Db Db
User User
Table_name Table_name
Column_name
権限フィールド Table_priv Column_priv
Column_priv
その他のフィールド Timestamp Timestamp
Grantor

各権限テーブルには、スコープフィールドと権限フィールドがあります。

スコープフィールドは、テーブルの各登録の範囲を特定します。たとえば、Host と User の値が 'thomas.loc.gov' および 'bob' である user テーブルエントリは、thomas.loc.gov ホストからサーバに接続しようとする bob を認証します。同様に、Host、User、Db の各フィールドの値が 'thomas.loc.gov'、'bob'、および 'reports' である db テーブルエントリは、thomas.loc.gov ホストから reports データベースに接続しようとする bob を認証します。tables_priv テーブルおよび columns_priv テーブルには、各エントリに許可されているテーブルまたはテーブルとカラムの組み合わせを示すスコープフィールドが含まれています。

アクセスをチェックする目的において、Host 値は大文字と小文字の区別がありません。User、Password、Db、および Table_name の値については大文字と小文字が区別されます。 Column_name 値は、MySQL バージョン 3.22.12 以降では大文字と小文字が区別されなくなっています。

権限フィールドは、テーブル内のエントリごとに設定されている権限、つまり何の操作を実行できるかを示します。サーバはさまざまな権限テーブルの情報を組み合わせて、ユーザの権限についての完全な記述を生成します。 この動作に適用されるルールについては、 「4.3.10 アクセス制御の段階 2: 要求確認」 を参照してください。

スコープフィールドは文字列です。ここで示されているように、それぞれのデフォルト値は空の文字列です。

フィールド名 型 注意
Host CHAR(60)
User CHAR(16)
Password CHAR(16)
Db CHAR(64) （tables_priv テーブルおよび columns_priv テーブルでは CHAR(60)）
Table_name CHAR(60)
Column_name CHAR(60)

user、db、host の各テーブルでは、すべての権限フィールドが ENUM('N','Y') として宣言されます。それぞれの値は 'N' または 'Y' で、デフォルト値は 'N' です。

tables_priv テーブルおよび columns_priv テーブルでは、権限フィールドは SET フィールドとして宣言されます。

テーブル名 フィールド名 設定可能な要素
tables_priv Table_priv 'Select', 'Insert', 'Update', 'Delete', 'Create', 'Drop', 'Grant', 'References', 'Index', 'Alter'
tables_priv Column_priv 'Select', 'Insert', 'Update', 'References'
columns_priv Column_priv 'Select', 'Insert', 'Update', 'References'

以下、サーバが権限テーブルをどのように使用するか簡潔に説明します。

注意: 管理者権限（RELOAD、SHUTDOWN など）は、user テーブルでのみ指定します。管理操作はデータベース固有ではなく、サーバそのもので行う操作なので、この権限を他の権限テーブルで設定する必要はありません。実際、管理操作を実行できるかどうか決定する際には、user テーブルを参照するだけで済みます。

FILE 権限も user テーブルだけで指定します。 これは管理者権限ではありませんが、サーバホスト上でのファイルの読み書きは、アクセスしているデータベースに依存しません。

mysqld サーバは権限テーブルの内容を、起動時に 1 回読み取ります。権限テーブルへの変更の反映については、 「4.4.3 権限の変更はいつ反映されるか」 を参照してください。

権限テーブルの内容を変更する場合、その変更によって、目的の権限が適切に設定されていることを確認してください。問題診断のヘルプについては、 「4.3.12 Access denied エラーの原因」 を参照してください。セキュリティに関するアドバイスについては、 「4.3.2 MySQL のクラッカー対策」 を参照してください。

便利な診断ツールとして、mysqlaccess スクリプトがあります。これは、Yves Carlier が MySQL ディストリビューション用に提供したものです。このツールの動作を確認したい場合には、mysqlaccess を --help オプションで起動してください。 注意: mysqlaccess は user、db、および host テーブルだけを使用してアクセスをチェックします。テーブルまたはカラムレベルの権限はチェックしません。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.3.7 MySQL が提供する権限

ユーザ権限に関する情報は、mysql データベース（mysql という名前のデータベース）の user、db、host、tables_priv、columns_priv の各テーブルに保存されています。MySQL サーバは起動時と、 「4.4.3 権限の変更はいつ反映されるか」 で説明されている状況下において、これらのテーブルを読み取ります。

以下、このマニュアルで使用されている MySQL バージョン 4.0.2 提供の権限名を、それに関連付けられているテーブルカラム名およびその適用範囲とともに示します。各権限の意味については、 「4.4.1 GRANT および REVOKE の構文」 を参照してください。

権限 カラム 適用範囲
ALTER Alter_priv テーブル
DELETE Delete_priv テーブル
INDEX Index_priv テーブル
INSERT Insert_priv テーブル
SELECT Select_priv テーブル
UPDATE Update_priv テーブル
CREATE Create_priv データベース、テーブル、またはインデックス
DROP Drop_priv データベースまたはテーブル
GRANT Grant_priv データベースまたはテーブル
REFERENCES References_priv データベースまたはテーブル
CREATE TEMPORARY TABLES Create_tmp_table_priv サーバ管理
EXECUTE Execute_priv サーバ管理
FILE File_priv サーバ上のファイルアクセス
LOCK TABLES Lock_tables_priv サーバ管理
PROCESS Process_priv サーバ管理
RELOAD Reload_priv サーバ管理
REPLICATION CLIENT Repl_client_priv サーバ管理
REPLICATION SLAVE Repl_slave_priv サーバ管理
SHOW DATABASES Show_db_priv サーバ管理
SHUTDOWN Shutdown_priv サーバ管理
SUPER Super_priv サーバ管理

SELECT、INSERT、UPDATE、DELETE の各権限は、データベース上の既存テーブルのレコードに対する各操作を許可するものです。

SELECT ステートメントは、テーブルからレコードを実際に取り出す場合のみ、SELECT 権限が必要となります。サーバのデータベースへのアクセス権がなくても実行できる SELECT ステートメントもあります。たとえば、mysql クライアントをシンプルな計算機として使用するような場合です。

 
mysql> SELECT 1+1;
mysql> SELECT PI()*2;

INDEX 権限では、インデックスを作成または破棄（削除）できます。

ALTER 権限では、ALTER TABLE を使用できます。

CREATE および DROP 権限では、新規データベースおよびテーブルの作成、既存データベースおよびテーブルの破棄（削除）を行えます。

注意: ユーザに mysql データベースに対する DROP 権限を与えると、そのユーザは MySQL アクセス権限が保存されているデータベースを破棄できるということになるので注意が必要です。

GRANT 権限では、ユーザが所有している権限を他のユーザに与えることができます。

FILE 権限では、LOAD DATA INFILE および SELECT ... INTO OUTFILE ステートメントを使用してサーバ上でファイルの読み書きを行えます。この権限を与えられたユーザはだれでも、MySQL サーバによってアクセス可能な読み取り可能ファイルをすべて読むことができ、また MySQL サーバによって書き込めるどのディレクトリにも新規読み取り可能ファイルを作成できます。 このユーザはまた、カレントデータベースディレクトリ内のすべてのファイルを読むことができます。 ただし、既存ファイルの変更はできません。

これら以外の権限は、mysqladmin プログラムを使用して実行される管理操作用に使用されます。以下の表で、どの管理権限でどの mysqladmin コマンドを実行できるかを示します。

権限 実行可能なコマンド
RELOAD reload、refresh、flush-privileges、flush-hosts、flush-logs、flush-tables
SHUTDOWN shutdown
PROCESS processlist
SUPER kill

reload コマンドは、権限テーブルを再読み込みするようにサーバに命令します。refresh コマンドは、すべてのテーブルをフラッシュし、ログファイルを開いて閉じます。flush-privileges は reload のシノニムです。他の flush-* コマンドも refresh と同様の機能を果たしますが、範囲が限られており、状況によって使い分けてください。たとえば、ログファイルだけをフラッシュするには、refresh の代わりに flush-logs を使用します。

shutdown コマンドはサーバをシャットダウンします。

processlist コマンドは、サーバで実行中のスレッドに関する情報を表示します。kill コマンドはサーバスレッドを強制終了します。ユーザはいつでも自分のスレッドを表示および強制終了することができますが、他のユーザによって開始されたスレッドを表示するには PROCESS 権限が、強制終了するには SUPER 権限が必要です。 「4.6.7 KILL 構文」 節 参照 。

一般的な指針として、ユーザにはそのユーザが必要とする権限だけを与えてください。また、以下の権限を与える際には注意が必要です。

MySQL 権限システムでは達成できないこともいくつかあります。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.3.8 MySQL サーバへの接続

MySQL クライアントでは通常、MySQL サーバにアクセスする際、接続先のホスト、ユーザ名、パスワードといった接続パラメータを指定する必要があります。たとえば、mysql クライアントは以下のように開始することができます（オプション引数は `[' と `]' で囲んであります）。

 
shell> mysql [-h host_name] [-u user_name] [-pyour_pass]

-h、-u、および -p オプションの別の形として、--host=host_name、--user=user_name、および --password=your_pass があります。注意: -p または --password= とそれに続くパスワードの間にスペースは入りません。

注意: コマンドラインでパスワードを指定するのは安全ではありません。 同じシステム内のどのユーザでも、ps auxww のようなコマンドを使用してパスワードを知ることができてしまいます。 「4.1.2 `my.cnf' オプション設定ファイル」 節 参照 。

mysql は、コマンドラインで指定されなかった接続パラメータに以下のデフォルト値を使用します。

したがって、Unix ユーザ joe では、以下のコマンドがいずれも同じ意味になります。

 
shell> mysql -h localhost -u joe
shell> mysql -h localhost
shell> mysql -u joe
shell> mysql

他の MySQL クライアントでも同様です。

Unix システムでは、接続時に別のデフォルト値を使用するように設定することができます。これにより、クライアントプログラムを起動するたびにコマンドラインで指定する必要がなくなります。設定方法は 2 つあります。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.3.9 アクセス制御の段階 1: 接続確認

ユーザが MySQL サーバに接続しようとした場合、そのユーザ ID、およびそれを正しいパスワードで裏付けできるかどうかによって、サーバは接続の許可または拒否を行います。パスワードが正しくない場合、サーバはアクセスを完全に拒否します。正しければ、サーバは接続を許可し、段階 2 に進んで要求を待ちます。

ユーザ ID は、2 つの情報に基づきます。

ID チェックには、user テーブルの 3 つのスコープフィールド（Host、User、Password）が使用されます。user テーブルエントリが、指定されたホスト名とユーザ名に一致し、入力したパスワードが正しかった場合のみ、接続が許可されます。

user テーブルのスコープフィールドには次の方法で値を指定できます。

空白ではない Password 値は、暗号化パスワードを表します。 MySQL では、パスワードを平文テキストでは保存しません。接続しようとするユーザが入力したパスワードは、暗号化されます（PASSWORD() 関数を使用）。クライアントおよびサーバがパスワードの確認を行う際、その暗号化されたパスワードが使用されます（このとき、その接続を使って、暗号化されたパスワードが転送されることはありません）。注意: MySQL から見ると暗号化されたパスワードが実際のパスワードなので、暗号化パスワードにだれにもアクセスできないようにしてください。特に、一般のユーザに mysql データベース内のテーブルの読み取りアクセス権を与えないでください。 バージョン 4.1 より、MySQL は従来とは異なるパスワードおよびログインメカニズムを採用しており、TCP/IP パケットが盗み見されたり、mysql データベースがキャプチャされた場合でも安全になっています。

以下の例は、user テーブルエントリの Host 値および User 値のさまざまな組み合わせがどのように着信の接続に適用されるかを示したものです。

Host 値 User 値 エントリによって許可される接続
'thomas.loc.gov' 'fred' thomas.loc.gov から接続する fred
'thomas.loc.gov' " thomas.loc.gov から接続するすべてのユーザ
'%' 'fred' 任意のホストから接続する fred
'%' " 任意のホストから接続するすべてのユーザ
'%.loc.gov' 'fred' loc.gov ドメイン内の任意のホストから接続する fred
'x.y.%' 'fred' x.y.net、x.y.com、x.y.edu などから接続する fred（これは実用的ではない）
'144.155.166.177' 'fred' IP アドレス 144.155.166.177 のホストから接続する fred
'144.155.166.%' 'fred' 144.155.166 クラス C サブネットの任意のホストから接続する fred
'144.155.166.0/255.255.255.0' 'fred' 1 つ上の例と同じ

Host フィールドでは IP のワイルドカード値を使用できるので（たとえば、'144.155.166.%' で、サブネットのすべてのホストに一致）、ホストを 144.155.166.somewhere.com などと名付けてこの機能が悪用される可能性があります。これを防ぐため、MySQL は数値やドットで始まるホスト名を認めません。したがって、1.2.foo.com などのホスト名は、権限テーブルの Host カラムと決して一致しません。IP アドレスのみ IP ワイルドカード値との突き合わせが可能です。

ある接続が、user テーブルの複数のエントリと一致することがあります。たとえば、thomas.loc.gov からの fred による接続は、上記の表のいくつかのエントリと一致します。複数のエントリが一致した場合、サーバは次のようにエントリを選択します。起動時に user テーブルを読み込んだ後、それをソートします。ユーザが接続しようとしたとき、そのソート順でエントリとの突き合わせを行います。そして最初に一致したエントリを使用します。

user テーブルのソートは以下のように行われます。user テーブルが以下の内容であるとします。

 
+-----------+----------+-
| Host      | User     | ...
+-----------+----------+-
| %         | root     | ...
| %         | jeffrey  | ...
| localhost | root     | ...
| localhost |          | ...
+-----------+----------+-

サーバがテーブルを読み込むと、最も具体的な Host 値を最初にもってきます（Host カラムの '%' は "任意のホスト" を意味し、具体性が低いとなります）。同じ Host 値のエントリ間で、最も具体的な User 値を最初にもってきます（空白の User 値は "任意のユーザ" を意味し、具体性が低いとなります）。ソートされた user テーブルは以下のようになります。

 
+-----------+----------+-
| Host      | User     | ...
+-----------+----------+-
| localhost | root     | ...
| localhost |          | ...
| %         | jeffrey  | ...
| %         | root     | ...
+-----------+----------+-

接続が試みられると、サーバはソートされたエントリで突き合わせを行い、最初に一致したものを使用します。localhost からの jeffrey による接続に対しては、Host カラムが 'localhost' のエントリが最初に一致します。これらのうち、空白ユーザ名のエントリが接続ホスト名とユーザ名の両方で一致します（'%'/'jeffrey' エントリも一致しますが、これはテーブル内での最初の突き合わせにはなりません）。

もう 1 つ例を示します。user テーブルが以下の内容であるとします。

 
+----------------+----------+-
| Host           | User     | ...
+----------------+----------+-
| %              | jeffrey  | ...
| thomas.loc.gov |          | ...
+----------------+----------+-

ソートされたテーブルは以下のようになります。

 
+----------------+----------+-
| Host           | User     | ...
+----------------+----------+-
| thomas.loc.gov |          | ...
| %              | jeffrey  | ...
+----------------+----------+-

thomas.loc.gov からの jeffrey による接続は最初のエントリと一致し、whitehouse.gov からの jeffrey による接続は 2 番目のエントリと一致します。

サーバが接続の突き合わせを行うとき、指定されたユーザ名を明示的に示すすべてのエントリが最初に使用されると誤解しがちです。これは間違っています。上記の例でもわかるように、thomas.loc.gov からの jeffrey による接続は、'jeffrey' が User フィールド値であるエントリではなく、ユーザ名なしのエントリと最初に一致します。

サーバへの接続がうまくいかない場合、user テーブルを出力して、最初の突き合わせがどれか確認してください。 正常に接続が行われても、権限が予期したものと違う場合、CURRENT_USER() 関数（バージョン 4.0.6 で導入）を使用して、その接続に実際に一致しているユーザとホストの組み合わせを確認できます。 「6.3.6.2 その他の各種関数」 節 参照 。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.3.10 アクセス制御の段階 2: 要求確認

接続が確立すると、サーバは段階 2 に移行します。その接続での要求ごとに、サーバはユーザにそれを実行できる権限があるかどうかを、操作タイプに基づいてチェックします。ここで、権限テーブルの権限フィールドが関係してきます。権限は、user、db、host、tables_priv、columns_priv のテーブルで設定できます。権限テーブルの設定は、GRANT コマンドと REVOKE コマンドで行います。 「4.4.1 GRANT および REVOKE の構文」 節 参照 。 各権限テーブルのフィールドのリストについては、 「4.3.6 権限システムはどのように機能するか」 を参照してください。

user テーブルは、カレントデータベースに関係なく、ユーザに対してグローバルに権限を設定します。たとえば、user テーブルで DELETE 権限が設定されたユーザは、そのサーバホストのどのデータベースのレコードでも削除できます。つまり、user テーブルで許可された権限はスーパーユーザ権限です。user テーブルで権限を設定する対象は、サーバ管理者やデータベース管理者などのスーパーユーザだけにしておくのが賢明です。他のユーザについては、user テーブルの権限を 'N' に設定しておき、db テーブルおよび host テーブルを使用してデータベース依存で権限を設定してください。

db テーブルおよび host テーブルは、データベース依存の権限を設定します。 スコープフィールドには次の方法で値を指定できます。

db テーブルおよび host テーブルは、サーバ起動時に読み取られてソートされます（user テーブル読み込みと同時）。db テーブルは Host、Db、および User のスコープフィールドでソートされ、host テーブルは Host と Db のスコープフィールドでソートされます。user テーブルでは、最も具体的な値が最初に、最も抽象的な値が最後にソートされ、サーバによるエントリの突き合わせでは、最初に一致したエントリが使用されます。

tables_priv テーブルと columns_priv テーブルはそれぞれ、テーブル依存およびカラム依存の権限を設定します。スコープフィールドには次の方法で値を指定できます。

tables_priv テーブルおよび columns_priv テーブルは、Host、Db、および User のフィールドでソートされます。これは db テーブルのソートと同様ですが、ワイルドカードの使用が Host フィールドだけに限定されるので、よりシンプルです。

以下、要求確認プロセスについて説明します。アクセスチェックのソースコードを知っている読者は、ここでの説明とコードで使用されるアルゴリズムに少し違いがあることに気付かれるでしょうが、説明はコードが実際に行うことと同じで、違いは説明をシンプルにするためのものです。

管理要求（SHUTDOWN、RELOAD など）に対して、サーバは user テーブルエントリだけをチェックします。管理権限を指定するのはこのテーブルのみであるためです。そのエントリが要求された操作を許可している場合はアクセスが認められ、そうでない場合は拒否されます。たとえば、mysqladmin shutdown を実行しようとしても、user テーブルエントリで SHUTDOWN 権限が設定されていなければ、db テーブルや host テーブルをチェックすることなくアクセスは拒否されます（これらのテーブルには Shutdown_priv カラムがなく、チェックの必要性がありません）。

データベース関連の要求（INSERT、UPDATE など）に対しては、サーバは最初に、user テーブルエントリでユーザのグローバル（スーパーユーザ）権限をチェックします。ここで、要求されている操作が許可されていれば、アクセスが認められます。user テーブルのグローバル権限では十分でない場合、サーバはユーザのデータベースに関する権限を db テーブルおよび host テーブルでチェックします。

  1. サーバは、db テーブルの Host、Db、User の各フィールドをチェックする。Host フィールドと User フィールドでは、接続ユーザのホスト名と MySQL ユーザ名がチェックされる。Db フィールドでは、ユーザがアクセスしようとしているデータベースがチェックされる。Host および User に該当するエントリがない場合、アクセスは拒否される。

  2. db テーブルに、マッチするエントリがあり、その Host フィールドが空白でなければ、そのエントリが、ユーザのデータベースに対する権限を定義する。

  3. db テーブルにある、マッチするエントリの Host フィールドが空白の場合、これは host テーブルが、データベースにアクセスできるホストを指定することを意味する。この場合、host テーブルの Host フィールドと Db フィールドがチェックされる。 host テーブル内にマッチするエントリがなければ、アクセスは拒否される。マッチするエントリがあれば、ユーザのデータベースに対する権限が、db および host テーブルエントリの（和集合ではなく）共通集合として計算される。これは、両方のエントリで 'Y' に設定されている権限を指す。このように、db テーブルエントリで全般的な権限を設定し、host テーブルエントリでホストごとに権限を制限することができる。

サーバは、db および host テーブルエントリからデータベースに対する権限を特定したら、それらの権限を user テーブルで設定されているグローバル権限に足し合わせます。その結果、要求されている操作が許可されていれば、アクセスが認められます。そうでない場合、サーバは tables_priv テーブルと columns_priv テーブルでユーザのテーブル権限とカラム権限をチェックし、これらをユーザの権限に追加します。その結果に基づき、アクセスが許可または拒否されます。

ブール値で表すと、上記のユーザ権限算出法は以下のようにまとめることができます。

 
グローバル権限
OR (database アクセス権 AND host アクセス権)
OR table アクセス権
OR column アクセス権

user 内のグローバル権限が十分ではない場合に、サーバがその不十分なグローバル権限を、データベース、テーブル、およびカラム権限と足し合わせる理由はわかりにくいかもしてません。 その理由は、要求に複数の権限が必要な場合があるからです。たとえば、INSERT ... SELECT ステートメントを実行するには、INSERT 権限および SELECT 権限の両方が必要です。 そのうち 1 つの権限が user テーブル内のエントリにあり、もう 1 つの権限が db テーブル内のエントリにある場合があります。その場合、要求を実行するのに必要な権限をユーザは持っていますが、サーバはどちらか一方のテーブルだけでは判断できません。この場合、両テーブルのエントリにある権限を組み合わせる必要があります。

host テーブルを使用して、セキュリティで保護されたサーバのリストを管理することができます。

TcX DataKonsult AB では、host テーブルに、ローカルネットワーク上のすべてのコンピュータの一覧を入れています。これらにすべての権限を設定しています。

host テーブルを使用して、セキュリティで保護されていないホストを示すこともできます。 セキュリティで保護されていない公開エリア内に、コンピュータ public.your.domain があるとします。以下のように、host テーブルのエントリを使用して、ネットワーク内のそのコンピュータ以外の全ホストにアクセスを許可することができます。

 
+--------------------+----+-
| Host               | Db | ...
+--------------------+----+-
| public.your.domain | %  | ... (全権限を 'N' にセット)
| %.your.domain      | %  | ... (全権限を 'Y' にセット)
+--------------------+----+-

当然、権限テーブルは常にテストして（mysqlaccess などを使用）、アクセス権限が目的どおりに設定されていることを確認してください。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.3.11 MySQL 4.1 のパスワードハッシュ

MySQL ユーザアカウントは、mysql データベースの user テーブルにリストアップされています。各 MySQL アカウントにはパスワードが割り当てられますが、user テーブルの Password カラムに保存されるのは平文テキストのパスワードではなく、パスワードから計算されたハッシュ値です。パスワードハッシュ値は、PASSWORD() 関数によって計算されます。

MySQL は、クライアントとサーバ間通信の 2 つのフェーズでパスワードを使用します。

つまり、クライアントが最初に接続しようとする際、サーバが認証するのにハッシュ値を使用します。接続したクライアントが PASSWORD() 関数を実行したり、GRANT または SET PASSWORD ステートメントを使用してパスワードの設定または変更を行うと、サーバがハッシュ値を生成します。

パスワードハッシュメカニズムは MySQL 4.1 で更新され、セキュリティが向上し、パスワード盗難の危険性が少なくなっています。 ただし、この新しいメカニズムは 4.1 サーバと 4.1 クライアントしか理解できないため、互換性の問題があります。 4.1 クライアントはパスワードハッシュの新旧メカニズムの両方を理解できるので、4.1 より前のサーバにでも接続できます。しかし、4.1 より前のクライアントが 4.1 サーバに接続しようとすると、問題が発生する可能性があります。たとえば、4.0 mysql クライアントが 4.1 サーバに接続しようとすると、以下のエラーメッセージが表示される可能性があります。

 
shell> mysql
Client does not support authentication protocol requested
by server; consider upgrading MySQL client

以下、以前のパスワードメカニズムと新しいパスワードメカニズムとの違い、およびサーバを 4.1 にアップグレードしたときに 4.1 より前のクライアントと互換性を保つ方法について説明します。

注意: ここでの説明は 4.1 とそれ以前の動作を対比するものですが、ここで説明する 4.1 の動作は実際には 4.1.1 からのものです。MySQL 4.1.0 の動作は、4.1.1 以降で導入されたメカニズムと少し異なります。4.1.0 とそれ以降のバージョンとの違いについては、後で説明します。

MySQL 4.1 より前は、PASSWORD() 関数によって計算されるパスワードハッシュは 16 バイト長でした。次に例を示します。

 
mysql> SELECT PASSWORD('mypass');
+--------------------+
| PASSWORD('mypass') |
+--------------------+
| 6f8c114b58f2ce9e   |
+--------------------+

MySQL 4.1 より前は、user テーブルの Password カラム（ハッシュが保存される場所）も 16 バイト長でした。

MySQL 4.1 から、PASSWORD() 関数が、より長い 41 バイトのハッシュ値を生成するようになっています。

 
mysql> SELECT PASSWORD('mypass');
+-----------------------------------------------+
| PASSWORD('mypass')                            |
+-----------------------------------------------+
| *43c8aa34cdc98eddd3de1fe9a9c2c2a9f92bb2098d75 |
+-----------------------------------------------+

したがって、この長さの値を保存するため、user テーブルの Password カラムも 41 バイト長であることが必要です。

拡張された Password カラムは、新旧どちらの形式のパスワードハッシュも保存できます。与えられたパスワードハッシュ値の形式は次の 2 つの違いにより判断されます。

長いパスワードハッシュ形式の方が暗号化の面で優れており、クライアント認証において旧形式の短いハッシュよりもセキュリティが高いと言えます。

パスワードハッシュの長短の違いは、認証時にサーバがパスワードを使用する方法と、パスワードを変更する接続クライアントに対してサーバがパスワードハッシュを生成する方法に関係してきます。

認証時にサーバがパスワードを使用する方法は、Password カラムの幅により次のような影響を受けます。

短いハッシュのアカウントでも、4.1 クライアントの方が旧クライアントよりも認証プロセスのセキュリティが少し向上しています。認証のセキュリティは以下の順で高くなります。

接続クライアントに対してサーバがパスワードハッシュを生成する方法は、Password カラムの幅と --old-passwords オプションにより影響を受けます。4.1 サーバは、次の条件が満たされた場合だけ、長いハッシュを生成します。 Password カラムが長いハッシュ値を保存できる長さであること、および --old-passwords オプションが指定されていないことが必要です。 これらの条件は以下のように適用されます。

--old-passwords オプションの目的は、サーバが長いパスワードハッシュを生成する環境において、4.1 より前のクライアントと下位互換性を保てるようにすることです。これは認証には影響しませんが（4.1 クライアントは長いパスワードハッシュのアカウントを使用できる）、パスワード変更操作の結果として user テーブルで長いパスワードハッシュが生成されることを防ぎます。長いパスワードハッシュが生成されると、そのアカウントは 4.1 より前のクライアントでは使用できなくなります。--old-passwords オプションを指定しない場合、以下のシナリオが想定されます。

このシナリオでは、4.1 より前の旧クライアントをサポートする必要がある場合、--old-passwords オプションを使用せずに 4.1 サーバを起動するのは危険であることを示しています。--old-passwords を指定してサーバを起動することにより、パスワード変更操作を行っても長いパスワードハッシュは生成されません。したがって、旧クライアントがアカウントにアクセスできなくなることがありません（旧クライアントが、パスワード変更時、偶発的に長いパスワードハッシュを生成して自らをロックアウトすることはありません）。

--old-passwords オプションの欠点は、4.1 クライアントでも、パスワード作成または変更時に短いハッシュを使用するということです。そのため、長いパスワードハッシュによる高いセキュリティを活用できません。4.1 クライアント用などに長いハッシュのアカウントを作成したい場合には、--old-passwords なしでサーバを実行する必要があります。

4.1 サーバの実行には以下のシナリオが想定されます。

シナリオ 1. user テーブルの短い Password カラム

シナリオ 2. 長い Password カラム、サーバを --old-passwords オプションなしで起動

上述したように、このシナリオでは、短いパスワードハッシュのアカウントに、4.1 より前のクライアントがアクセスできなくなる危険性があります。GRANT、SET PASSWORD、または PASSWORD() を使用してアカウントのパスワードを変更すると、新規パスワードハッシュが長くなるため、4.1 より前のクライアントは、4.1 にアップグレードしないとそのアカウントを認証できなくなります。

シナリオ 3. 長い Password カラム、サーバを --old-passwords オプションで起動

このシナリオでは、--old-passwords によって長いハッシュが生成されないため、長いパスワードハッシュのアカウントを作成できません。また、--old-passwords オプションを使用する前に長いハッシュのアカウントを作成した場合でも、--old-passwords の有効時にアカウントのパスワードを変更すると短いパスワードになってしまうので、長いハッシュが持つセキュリティ上の利点が失われます。

これらのシナリオの欠点はそれぞれ以下のように要約できます。

シナリオ 1. セキュリティの高い認証を提供する長いハッシュを活用できない。

シナリオ 2. OLD_PASSWORD() を使用せずにパスワードを変更すると、短いハッシュのアカウントに 4.1 より前のクライアントがアクセスできなくなる。

シナリオ 3. --old-passwords によって、短いハッシュのアカウントがアクセス不能になることは防がれるが、長いハッシュをパスワード変更すると短いハッシュになってしまい、--old-passwords が有効な間はそれを元の長さに戻せない。

アプリケーションプログラムに対するパスワードハッシュ変更の影響

MySQL 4.1 にアップグレードすると、独自の目的で PASSWORD() を使用してパスワードを生成するアプリケーションとの互換性に問題が生じます。本来、PASSWORD() は MySQL ユーザのパスワード管理専用なので、アプリケーションでこれを実行すべきではありません。しかし現状では、いくつかのアプリケーションが独自の目的で PASSWORD() を使用しています。4.1 にアップグレードし、長いパスワードハッシュが生成される状態でサーバを実行すると、独自の目的で PASSWORD() を使用するアプリケーションは壊れます。推奨される対処法は、アプリケーションを修正して SHA1() または MD5() など、別の関数を使用してハッシュ値を生成するように設定することです。 それが可能でなければ、OLD_PASSWORD() 関数を使用することができます。これは、旧形式の短いハッシュを生成するためのものです（注意: ただし、OLD_PASSWORD() は将来サポートされなくなる可能性があります）。

短いハッシュを生成する状態でサーバが実行中の場合、OLD_PASSWORD() は利用可能ですが、PASSWORD() と同じになります。

MySQL 4.1.0 のパスワードハッシュは 4.1.1 以降のパスワードハッシュと異なります。 4.1.0 の違いは以下のとおりです。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.3.12 Access denied エラーの原因

MySQL サーバに接続しようとして Access denied エラーが発生した場合の対処法を、以下に示します。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.4 MySQL のユーザ管理

4.4.1 GRANT および REVOKE の構文   
4.4.2 MySQL のユーザ名とパスワード   
4.4.3 権限の変更はいつ反映されるか   
4.4.4 MySQL 権限の初期設定   
4.4.5 MySQL への新規ユーザの追加   
4.4.6 MySQL ユーザの削除   
4.4.7 ユーザリソースの制限   
4.4.8 パスワードの設定   
4.4.9 パスワードのセキュリティ   
4.4.10 安全な接続の使用   

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.4.1 GRANT および REVOKE の構文

 
GRANT priv_type [(column_list)] [, priv_type [(column_list)] ...]
    ON {tbl_name | * | *.* | db_name.*}
    TO user_name [IDENTIFIED BY [PASSWORD] 'password']
        [, user_name [IDENTIFIED BY [PASSWORD] 'password'] ...]
    [REQUIRE
        NONE |
        [{SSL| X509}]
        [CIPHER cipher [AND]]
        [ISSUER issuer [AND]]
        [SUBJECT subject]]
    [WITH [GRANT OPTION | MAX_QUERIES_PER_HOUR # |
                          MAX_UPDATES_PER_HOUR # |
                          MAX_CONNECTIONS_PER_HOUR #]]

REVOKE priv_type [(column_list)] [, priv_type [(column_list)] ...]
    ON {tbl_name | * | *.* | db_name.*}
    FROM user_name [, user_name ...]

GRANT は、MySQL バージョン 3.22.11 以降で実装されています。それより前の MySQL バージョンでは、GRANT ステートメントは何もしません。

システム管理者は、GRANT コマンドと REVOKE コマンドを使用して、ユーザを作成し、MySQL ユーザに対して次の 4 つのレベルの権限を与えたり取り消すことができます。

グローバルレベル
グローバル権限は特定のサーバ上のすべてのデータベースに適用される。これらの権限は、mysql.user テーブルに保存される。 GRANT ALL ON *.* および REVOKE ALL ON *.* は、グローバル権限の付与および取り消しのみを行う。

データベースレベル
データベース権限は、指定したデータベースのすべてのテーブルに適用される。これらの権限は、mysql.db テーブルおよび mysql.host テーブルに保存される。 GRANT ALL ON db.* および REVOKE ALL ON db.* は、データベース権限の付与および取り消しのみを行う。

テーブルレベル
テーブル権限は、指定したテーブルのすべてのカラムに適用される。これらの権限は、mysql.tables_priv テーブルに保存される。 GRANT ALL ON db.table および REVOKE ALL ON db.table は、テーブル権限の付与および取り消しのみを行う。

カラムレベル
カラム権限は、指定したテーブルの一つのカラムに適用される。これらの権限は、mysql.columns_priv テーブルに保存される。 REVOKE を使用する際は、対象となるカラムを指定することが必要である。

GRANT および REVOKE ステートメントの priv_type には以下のいずれかを指定できます。

ALL [PRIVILEGES] WITH GRANT OPTION 以外のすべての権限を設定
ALTER ALTER TABLE の使用を許可
CREATE CREATE TABLE の使用を許可
CREATE TEMPORARY TABLES CREATE TEMPORARY TABLE の使用を許可
DELETE DELETE の使用を許可
DROP DROP TABLE の使用を許可
EXECUTE ストアドプロシージャの使用を許可（MySQL 5.0）
FILE SELECT ... INTO OUTFILE および LOAD DATA INFILE の使用を許可
INDEX CREATE INDEX および DROP INDEX の使用を許可
INSERT INSERT の使用を許可
LOCK TABLES SELECT 権限を持つテーブルで LOCK TABLES の使用を許可
PROCESS SHOW FULL PROCESSLIST の使用を許可
REFERENCES 将来のために予約
RELOAD FLUSH の使用を許可
REPLICATION CLIENT スレーブおよびマスタのサーバーを知る権利を付与
REPLICATION SLAVE レプリケーションのスレーブに必要（マスタからバイナリログを読み取るため）
SELECT SELECT の使用を許可
SHOW DATABASES SHOW DATABASES によりすべてのデータベースが表示される
SHUTDOWN mysqladmin shutdown の使用を許可
SUPER 最大接続数に達していても接続を 1 つだけ許可し、コマンド CHANGE MASTER、KILL thread、mysqladmin debug、PURGE MASTER LOGS、および SET GLOBAL の実行を許可
UPDATE UPDATE の使用を許可
USAGE "権限なし" のシノニム
GRANT OPTION WITH GRANT OPTION のシノニム

USAGE を使用すると、権限なしのユーザを作成できます。

CREATE TEMPORARY TABLES、EXECUTE、LOCK TABLES、REPLICATION ...、SHOW DATABASES、および SUPER は、バージョン 4.0.2 で新しく導入された権限です。4.0.2 にアップグレードした後でこれらの権限を使用するには、mysql_fix_privilege_tables スクリプトを実行する必要があります。 「2.5.6 権限テーブルのアップグレード」 節 参照 。

古い MySQL バージョンでは、PROCESS 権限が新しい SUPER 権限と同じ働きをします。

ユーザの GRANT 権限を取り消すには、次のように priv_type 値として GRANT OPTION を使用します。

 
mysql> REVOKE GRANT OPTION ON ... FROM ...;

テーブルに対して指定できる priv_type 値は、SELECT、INSERT、UPDATE、DELETE、CREATE、DROP、GRANT OPTION、INDEX、および ALTER だけです。

カラムに対して指定できる（つまり、column_list 節を使用する場合の）priv_type 値は、SELECT、INSERT、および UPDATE だけです。

MySQL では、データベースが存在しない場合でもデータベースレベルの権限を作成でき、データベース使用の準備を行えます。 ただし現在のところ、テーブルが存在しない場合にはテーブルレベルの権限は作成できません。テーブルやデータベースを破棄した場合でも、MySQL が自動的に権限を取り消すことはありません。

グローバル権限は ON *.* 構文を使用して設定できます。データベース権限は ON db_name.* 構文を使用して設定できます。ON * を指定したときにカレントデータベースがあれば、そのデータベースの権限が設定されます。警告: ON * を指定したときにカレントデータベースがなければ、グローバル権限に影響します。

注意: GRANT コマンドでデータベース名を指定する際、`_' および `%' ワイルドカードを使用できます。データベース名の一部として、たとえば `_' 文字を使用したい場合、GRANT コマンドでは GRANT ... ON `foo\_bar`.* TO ... などのように、`\_' として指定するようしてください。そうしないと、ワイルドカードパターンに一致する別のデータベースにもユーザがアクセスできるようになります。

MySQL では、任意のホストのユーザに権限を付与できるように、user_name 値を user@host 形式で指定できるようになっています。特殊文字（`-' など）を含む user 文字列を指定したり、特殊文字またはワイルドカード文字（`%' など）を含む host 文字列を指定したい場合、ユーザ名またはホスト名を引用符で囲むことができます（たとえば、'test-user'@'test-hostname'）。

ホスト名にワイルドカードを使用できます。たとえば、user@'%.loc.gov' は loc.gov ドメインのどのホストの user にも当てはまり、user@'144.155.166.%' は 144.155.166 クラス C のどのホストの user にも当てはまります。

シンプルな形式 user は user@"%" のシノニムです。

MySQL では、ユーザ名でのワイルドカード使用をサポートしていません。匿名ユーザの定義には、User=" のエントリを mysql.user テーブルに挿入するか、GRANT コマンドで空白名のユーザを作成します。

注意: 匿名ユーザが MySQL サーバに接続できるようにする場合、すべてのローカルユーザに対して、user@localhost として権限を設定する必要があります。そうしないと、ユーザがローカルマシンから MySQL サーバにログインしようとしたときに、mysql.user テーブルのローカルホストの匿名ユーザエントリが使用されるからです。

これを確認するには、以下のクエリを実行します。

 
mysql> SELECT Host,User FROM mysql.user WHERE User='';

現在のところ、GRANT ではホスト、テーブル、データベース、およびカラムの名前に最大 60 文字まで使用できます。ユーザ名は最大 16 文字までです。

テーブルまたはカラムに対する権限は、4 つのレベルの権限の論理和（OR）で形成されます。たとえば、mysql.user テーブルでユーザにグローバル SELECT 権限が設定されている場合、これがデータベース、テーブル、またはカラムレベルのエントリで拒否されることはありません。

カラムに対する権限は以下のように計算されます。

 
global privileges
OR (database privileges AND host privileges)
OR table privileges
OR column privileges

多くの場合、ユーザへの権限設定には権限レベルを 1 つだけしか使用しないので、上述のように複雑にはなりません。権限チェックプロシージャの詳細については、 「4.3 一般的なセキュリティ関連事項と MySQL アクセス制御システム」 を参照してください。

mysql.user テーブルに存在しないユーザとホスト名の組み合わせに権限を付与すると、そのエントリはテーブルに追加され、DELETE コマンドで削除されるまでそこに残ります。つまり、GRANT で user テーブルエントリを作成できますが、REVOKE ではそのエントリを削除できません。削除するには明示的に DELETE を使用する必要があります。

MySQL バージョン 3.22.12 以降では、新規ユーザが作成された場合、またはグローバル権限を付与する場合、IDENTIFIED BY 節でパスワードが指定されていれば、それがそのユーザのパスワードになります。すでにユーザにパスワードがある場合は、新しいパスワードに置き換えられます。

テキスト形式でパスワードを送信するのが望ましくなければ、PASSWORD オプションを使用して、SQL 関数 PASSWORD() または C API 関数 make_scrambled_password(char *to, const char *password) で生成した暗号化パスワードを設定できます。

警告: 新規ユーザを作成した際、IDENTIFIED BY 節を指定しなければそのユーザはパスワードなしになります。つまり、危険です。

パスワードの設定には、SET PASSWORD コマンドを使用することもできます。 「5.5.6 SET 構文」 節 参照 。

データベースに対する権限を設定する場合、必要に応じて mysql.db テーブルにエントリが作成されます。REVOKE でそのデータベースのすべての権限が削除されると、このエントリも削除されます。

ユーザがテーブルに何の権限も持っていない場合、SHOW TABLES ステートメントなどでテーブルのリストを要求しても、テーブルは表示されません。SHOW DATABASES でも同様です。

WITH GRANT OPTION 節を使用すると、ユーザは自分が所有する権限を他のユーザに与えることができます。 GRANT 権限をユーザに設定する際は注意が必要です。2 人のユーザがお互いの権限を組み合わせることが可能になるからです。

MAX_QUERIES_PER_HOUR #、MAX_UPDATES_PER_HOUR #、および MAX_CONNECTIONS_PER_HOUR # は MySQL バージョン 4.0.2 で新しく導入されました。 これらのオプションは、1 時間でユーザが実行できるクエリ、更新、およびログインの回数を制限します。# が 0（デフォルト）の場合、そのユーザに制限はないということです。 「4.4.7 ユーザリソースの制限」 節 参照 。 注意: 既存ユーザに追加権限を設定することなくこれらのオプションを指定するには、GRANT USAGE ON *.* ... WITH MAX_... を使用します。

自分自身が持っていない権限を他のユーザに与えることはできません。GRANT 権限では、自分が所有する権限だけを他のユーザに与えることができます。

あるレベルの GRANT 権限をユーザに設定すると、そのユーザがそのレベルで所有する（および将来所有する）すべての権限を、そのユーザは他のユーザに設定できるということに注意してください。 あるユーザにデータベースに対する INSERT 権限を付与したと仮定します。次にデータベースの SELECT 権限を付与する際 WITH GRANT OPTION を指定した場合、そのユーザは SELECT 権限だけでなく INSERT 権限も他のユーザに与えることができます。さらにデータベースの UPDATE 権限をそのユーザに与えると、そのユーザは INSERT、SELECT、および UPDATE 権限を他のユーザに与えることができるようになります。

ALTER 権限は一般ユーザには付与しないでください。設定すると、そのユーザはテーブルの名前を変更して、権限システムを破ることができるようになります。

注意: 1 人のユーザだけにテーブル権限またはカラム権限を設定した場合でも、サーバはすべてのユーザのテーブル権限とカラム権限を調べるため、MySQL の処理速度は少し低下します。

mysqld の起動時、すべての権限がメモリに読み込まれます。 データベース権限、テーブル権限、およびカラム権限はすぐに反映されますが、ユーザレベルの権限はユーザが次回接続したときに有効となります。 GRANT または REVOKE によって行われた権限テーブルへの変更については、サーバは即座に認識します。 INSERT、UPDATE などを使って手動で権限テーブルを変更した場合、FLUSH PRIVILEGES ステートメントまたは mysqladmin flush-privileges を実行してサーバに権限テーブルを再読み込みさせる必要があります。 「4.4.3 権限の変更はいつ反映されるか」 節 参照 。

GRANT の標準 SQL のバージョンと MySQL バージョンでの最大の違いは以下のとおりです。

REQUIRE の使用法については、 「4.4.10 安全な接続の使用」 を参照してください。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.4.2 MySQL のユーザ名とパスワード

MySQL でのユーザ名およびパスワードの使用法と、Unix および Windows での使用法にはいくつかの相違点があります。

MySQL ユーザおよびその権限は通常、GRANT コマンドで作成します。 「4.4.1 GRANT および REVOKE の構文」 節 参照 。

MySQL サーバにコマンドラインクライアントでログインする場合は、--password=your-password でパスワードを指定してください。 「4.3.8 MySQL サーバへの接続」 節 参照 。

 
mysql --user=monty --password=guess database_name

クライアントにパスワードを要求させたい場合には、引数なしで --password を使用します。

 
mysql --user=monty --password database_name

または次の短い形式

 
mysql -u monty -p database_name

注意: 上記の例で、パスワードが 'database_name' なわけではありません。

-p オプションを使用してパスワードを指定するには、以下のように行います。

 
mysql -u monty -pguess database_name

システムによっては、MySQL がパスワードを要求する際のライブラリコールにより、自動的にパスワードが 8 文字に切り詰められます。MySQL の内部では、パスワード長に制限はありません。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.4.3 権限の変更はいつ反映されるか

mysqld の起動時、すべての権限テーブルがメモリに読み込まれ、この時点で有効となります。

GRANT、REVOKE、または SET PASSWORD を使用して行った権限テーブルの変更は、すぐにサーバに認識されます。

INSERT、UPDATE などを使用して手動で権限テーブルを変更した場合、FLUSH PRIVILEGES ステートメント、mysqladmin flush-privileges、または mysqladmin reload を実行してサーバに権限テーブルを再読み込みさせる必要があります。そうしなければ、サーバを再起動するまで、変更は反映されません。権限テーブルを手動で変更した後、権限の再読み込みを忘れると、当然変更は反映されません。

サーバが権限テーブルの変更を認識すると、既存のクライアント接続は以下のような影響を受けます。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.4.4 MySQL 権限の初期設定

MySQL のインストール後、scripts/mysql_install_db を実行してアクセス権限を初期設定します。 「2.3.1 クイックインストールの概要」 節 参照 。 mysql_install_db スクリプトは mysqld サーバを起動し、以下の権限を含むように権限テーブルを初期化します。

注意: Windows のデフォルト権限とは異なります。 「2.1.1.8 Windows での MySQL の実行」 節 参照 。

初期インストール時はアクセスが開放されている状態なので、インストール後はまず、MySQL root ユーザにパスワードを設定してください。これは以下のように行います（注意: PASSWORD() 関数を使用してパスワードを指定します）。

 
shell> mysql -u root mysql
mysql> SET PASSWORD FOR root@localhost=PASSWORD('new_password');

'new_password' に、使用するパスワードを指定します。

方法を理解していれば、権限テーブルを直接操作することもできます。

 
shell> mysql -u root mysql
mysql> UPDATE user SET Password=PASSWORD('new_password')
    ->     WHERE user='root';
mysql> FLUSH PRIVILEGES;

mysqladmin コマンドを使用しても、パスワードを設定できます。

 
shell> mysqladmin -u root password new_password

mysql データベースの書き込み権限および更新権限のあるユーザだけが、他のユーザのパスワードを変更できます。すべての一般ユーザ（匿名ユーザ以外）は、上記のコマンドまたは SET PASSWORD=PASSWORD('new_password') を使用して自分のパスワードだけを変更できます。

注意: UPDATE を使用して user テーブルで直接パスワードを更新する場合、FLUSH PRIVILEGES を使用してサーバに権限テーブルを再読み込みさせる必要があります。そうしないと変更が認識されません。

root パスワードをいったん設定するとそれ以降、root としてサーバに接続する際は常にそのパスワードを入力する必要があります。

追加設定やテストを行っている最中にパスワードを入力しないで済むように、root パスワードを空白のままにしたい場合もあるでしょう。しかし、実稼動で使用する前には必ずパスワードを設定してください。

デフォルト権限の設定については、scripts/mysql_install_db スクリプトを参照してください。このスクリプトは、他のユーザを追加する際にその基本として使用できます。

上記の初期権限とは違う初期権限を設定したい場合には、mysql_install_db を編集してから実行してください。

権限テーブルを完全に再生成するには、mysql データベースが含まれるディレクトリ内の `.frm'、`.MYI'、および `.MYD' ファイルをすべて削除します（このディレクトリは、データディレクトリの下にある `mysql' という名前のディレクトリです。データディレクトリは mysqld --help を実行すると表示されます）。そして、必要に応じて権限を編集してから、mysql_install_db スクリプトを実行します。

注意: MySQL バージョン 3.22.10 より前では、`.frm' ファイルを削除しないでください。うっかり削除してしまった場合は、mysql_install_db を実行する前に、MySQL ディストリビューションからコピーし直してください。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.4.5 MySQL への新規ユーザの追加

ユーザの追加には、2 つの方法があります。GRANT ステートメントを使用する方法と、MySQL 権限テーブルを直接操作する方法です。正確でエラーが発生しにくい GRANT ステートメントの使用を推奨します。 「4.4.1 GRANT および REVOKE の構文」 節 参照 。

ユーザの作成および管理に使用できるコントリビューションプログラムもいくつかあります（phpMyAdmin など）。

以下の例では、mysql クライアントを使用して新規ユーザを設定する方法を示します。この例では、前のセクションで説明したデフォルト設定に従って権限がセットアップされていることを前提にしています。そのため変更を行うには、mysqld を実行しているマシンにログインしていること、MySQL root ユーザとして接続していること、root ユーザに mysql データベースに対する INSERT 権限と RELOAD 管理者権限があることが必要条件となります。また、root ユーザパスワードを変更している場合、ここで、mysql コマンドを使用してそのパスワードを指定する必要があります。

まず、mysql プログラムを使用してサーバに MySQL root ユーザとして接続します。

 
shell> mysql --user=root mysql

次に、GRANT ステートメントを実行して新規ユーザを追加できます。

 
mysql> GRANT ALL PRIVILEGES ON *.* TO monty@localhost
    ->     IDENTIFIED BY 'some_pass' WITH GRANT OPTION;
mysql> GRANT ALL PRIVILEGES ON *.* TO monty@'%'
    ->     IDENTIFIED BY 'some_pass' WITH GRANT OPTION;
mysql> GRANT RELOAD,PROCESS ON *.* TO admin@localhost;
mysql> GRANT USAGE ON *.* TO dummy@localhost;

これらの GRANT ステートメントでは、以下の 3 人の新規ユーザが追加されます。

monty
どこからでもサーバに接続できる完全なスーパーユーザ。ただし、パスワード 'some_pass' の使用が必要。注意: GRANT ステートメントを monty@localhost と monty@"%" の両方に対して発行することが必要である。localhost のエントリを追加しないと、ローカルホストから接続したとき、mysql_install_db によって作成された localhost のエントリの方が、Host フィールド値がより具体的であり、user テーブルのソート順序で上位になるため優先されることになる。

admin
localhost からパスワードなしで接続でき、RELOAD および PROCESS の管理権限のあるユーザ。このユーザは、mysqladmin reload、mysqladmin refresh、mysqladmin flush-* の各コマンド、および mysqladmin processlist を実行できる。データベースレベルの権限は設定されていない（GRANT ステートメントを実行して後で追加できる）。

dummy
パスワードなしでローカルホストからのみ接続できるユーザ。権限は設定されていない。USAGE 権限タイプにより、このような権限なしのユーザを作成できる。これは、すべてのグローバル権限を 'N' に設定するのと同じことである。これは、後でこのアカウントに固有の権限を設定することを想定している。

INSERT ステートメントを発行してサーバに権限テーブルを再度読み込ませることにより、同じユーザアクセス情報を直接追加することもできます。

 
shell> mysql --user=root mysql
mysql> INSERT INTO user VALUES('localhost','monty',PASSWORD('some_pass'),
    ->          'Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y');
mysql> INSERT INTO user VALUES('%','monty',PASSWORD('some_pass'),
    ->          'Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y');
mysql> INSERT INTO user SET Host='localhost',User='admin',
    ->           Reload_priv='Y', Process_priv='Y';
mysql> INSERT INTO user (Host,User,Password)
    ->                  VALUES('localhost','dummy','');
mysql> FLUSH PRIVILEGES;

MySQL バージョンによっては、上記 'Y' 値の数が違う場合があります（3.22.11 より前のバージョンでは権限カラムが少なく、4.0.2 以降では多くなります）。admin ユーザに対しては、バージョン 3.22.11 以降で利用可能になった SET を使用する拡張 INSERT 構文が使用されています。

注意: スーパーユーザを設定する場合は、権限フィールドを 'Y' に設定した user テーブルエントリを作成するだけで済みます。db テーブルや host テーブルのエントリは必要ありません。

最後の INSERT ステートメント（dummy ユーザ）では、user テーブルレコードの Host、User、および Password カラムだけが値を割り当てられています。権限カラムはどれも明示的に設定されていないため、MySQL はこれらすべてにデフォルト値の 'N' を設定します。これは、GRANT USAGE と同じ機能です。

以下の例では、ユーザ custom を追加します。このユーザは bankaccount データベースにはローカルホストからのみ、expenses データベースにはホスト whitehouse.gov からのみ、customer データベースにはホスト server.domain からのみアクセスできるとします。3 つのホストすべてでパスワード obscure を使用します。

GRANT ステートメントを使用してこのユーザの権限を設定するには、以下のコマンドを実行します。

 
shell> mysql --user=root mysql
mysql> GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP
    ->     ON bankaccount.*
    ->     TO custom@localhost
    ->     IDENTIFIED BY 'obscure';
mysql> GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP
    ->     ON expenses.*
    ->     TO custom@'whitehouse.gov'
    ->     IDENTIFIED BY 'obscure';
mysql> GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP
    ->     ON customer.*
    ->     TO custom@'server.domain'
    ->     IDENTIFIED BY 'obscure';

権限テーブルを直接変更してユーザの権限を設定するには、以下のコマンドを実行します（注意: 最後の FLUSH PRIVILEGES に注目）。

 
shell> mysql --user=root mysql
mysql> INSERT INTO user (Host,User,Password)
    -> VALUES('localhost','custom',PASSWORD('obscure'));
mysql> INSERT INTO user (Host,User,Password)
    -> VALUES('whitehouse.gov','custom',PASSWORD('obscure'));
mysql> INSERT INTO user (Host,User,Password)
    -> VALUES('server.domain','custom',PASSWORD('obscure'));
mysql> INSERT INTO db
    -> (Host,Db,User,Select_priv,Insert_priv,Update_priv,Delete_priv,
    ->  Create_priv,Drop_priv)
    -> VALUES
    -> ('localhost','bankaccount','custom','Y','Y','Y','Y','Y','Y');
mysql> INSERT INTO db
    -> (Host,Db,User,Select_priv,Insert_priv,Update_priv,Delete_priv,
    ->  Create_priv,Drop_priv)
    -> VALUES
    -> ('whitehouse.gov','expenses','custom','Y','Y','Y','Y','Y','Y');
mysql> INSERT INTO db
    -> (Host,Db,User,Select_priv,Insert_priv,Update_priv,Delete_priv,
    ->  Create_priv,Drop_priv)
    -> VALUES('server.domain','customer','custom','Y','Y','Y','Y','Y','Y');
mysql> FLUSH PRIVILEGES;

INSERT ステートメントを使用した前の例と同様、MySQL のバージョンによっては 'Y' の値の数が異なります。

最初の 3 つの INSERT ステートメントは user テーブルエントリを追加し、ユーザ custom がさまざまなホストから指定のパスワードで接続できるようにしますが、権限については何も設定していません（権限はすべて、デフォルト値の 'N' に設定されています）。次の 3 つの INSERT ステートメントは、db テーブルエントリを追加し、custom に bankaccount、expenses、customer の各データベースに対する権限を設定します。これらの権限は、適切なホストからアクセスしたときにだけ適用されるものです。権限テーブルを直接変更した場合、FLUSH PRIVILEGES を使用してサーバに権限テーブルを再度読み込ませ、権限の変更を反映させる必要があります。

特定のユーザに、あるドメイン（たとえば mydomain.com）のすべてのマシンからのアクセスを許可するには、以下のような GRANT ステートメントを実行します。

 
mysql> GRANT ...
    ->     ON *.*
    ->     TO myusername@'%.mydomain.com'
    ->     IDENTIFIED BY 'mypassword';

権限テーブルを直接変更して同じことを行うには、以下を実行します。

 
mysql> INSERT INTO user VALUES ('%.mydomain.com', 'myusername',
    ->             PASSWORD('mypassword'),...);
mysql> FLUSH PRIVILEGES;

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.4.6 MySQL ユーザの削除

 
DROP USER user_name

このコマンドは MySQL 4.1.1 で追加されたコマンドです。

このコマンドにより、権限を持たないユーザが削除されます。

MySQL からユーザを削除するには、以下の手順に従います。

  1. SHOW PRIVILEGES を使用してユーザの権限を確認する。 「4.6.8.11 SHOW PRIVILEGES」 節 参照 。
  2. REVOKE を使用してユーザから権限をすべて削除する。 「4.4.1 GRANT および REVOKE の構文」 節 参照 。
  3. DROP USER を使用してユーザを削除する。

古い MySQL バージョンを使用している場合は、まず権限を取り消してからユーザを削除します。

 
mysql> DELETE FROM mysql.user WHERE user='username' and host='hostname';
mysql> FLUSH PRIVILEGES;

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.4.7 ユーザリソースの制限

MySQL 4.0.2 以降、特定のリソースをユーザごとに制限できるようになりました。

今までは、MySQL サーバリソースの使用を制限するには、スタートアップ変数の max_user_connections をゼロ以外の値に設定するしかありませんでした。しかしこの方法はグローバルに適用されるため、インターネットサービスプロバイダが関心のある個別ユーザの管理には使用できませんでした。

そのため、個別ユーザレベルで 3 つのリソースを管理する方法が導入されました。

上記コンテキストの 1 ユーザとは user テーブルの 1 エントリです。このエントリは user カラムと host カラムによって識別されます。

制限を設定しない限り、すべてのユーザはデフォルトで、上記リソースを制限なく使用できます。これらの制限は、以下の構文を使用してグローバルな GRANT (*.*) でのみ設定できます。

 
GRANT ... WITH MAX_QUERIES_PER_HOUR N1
               MAX_UPDATES_PER_HOUR N2
               MAX_CONNECTIONS_PER_HOUR N3;

上記のリソースはどのような組み合わせでも指定可能です。 N1、N2、および N3 は整数で、時間単位のカウント数を表します。

ユーザが時間単位の接続数に達すると、その 1 時間が経過するまで、以降の接続は拒否されます。同様に、ユーザがクエリまたは更新の制限回数に達すると、その 1 時間が経過するまで、以降のクエリまたは更新は拒否されます。いずれの場合も、適切なエラーメッセージが表示されます。

特定ユーザの現在の使用値をフラッシュ（ゼロに設定）するには、上記の任意の節の GRANT ステートメントを発行します。その際 GRANT ステートメントの値を現在の値にします。

また、すべてのユーザの現在の値をフラッシュするには、権限を再読み込みするか（サーバ内部で行うか、mysqladmin reload を使用）、FLUSH USER_RESOURCES コマンドを実行します。

リソース制限機能は、単一ユーザにリソースを制限する GRANT 節が設定されるとすぐに有効になります。

この機能を有効化する前提条件として、`scripts' サブディレクトリにあるテーブル作成スクリプト mysql_install_db および mysql_install_db.sh で定義されている追加カラムが、mysql データベースの user テーブルに含まれていることが必要です。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.4.8 パスワードの設定

ほとんどの場合において、ユーザとパスワードの設定には GRANT を使用します。以下の方法は上級ユーザ対象です。 「4.4.1 GRANT および REVOKE の構文」 節 参照 。

前のセクションでは、例を用いて重要な原則を示しました。INSERT または UPDATE ステートメントを使用して空白でないパスワードを保存する際には、PASSWORD() 関数を使用して暗号化しなければならないということです。これは、user テーブルがパスワードを平文テキストではなく、暗号化された形式で保存するためです。たとえば、この原則を忘れて、以下のようにパスワードを設定してしまったとします。

 
shell> mysql -u root mysql
mysql> INSERT INTO user (Host,User,Password)
    -> VALUES('%','jeffrey','biscuit');
mysql> FLUSH PRIVILEGES;

この場合、平文テキストの 'biscuit' が、パスワードとして user テーブルに保存されます。ユーザ jeffrey がこのパスワードを使用してサーバに接続しようとすると、mysql クライアントは PASSWORD() でそれを暗号化し、暗号化されたパスワードと、サーバから取得したランダム番号に基づいて認証ベクトルを生成し、それをサーバに送信します。 サーバは user テーブルの password 値（この場合、暗号化されていない 'biscuit'）を使用して同じ計算を実行し、結果を比較します。 比較は失敗し、サーバは接続を拒否します。

 
shell> mysql -u jeffrey -pbiscuit test
Access denied

user テーブルにパスワードを挿入するとき、パスワードは暗号化しておく必要があります。したがって、INSERT ステートメントを以下のように指定します。

 
mysql> INSERT INTO user (Host,User,Password)
    -> VALUES('%','jeffrey',PASSWORD('biscuit'));

SET PASSWORD ステートメントを使用するときも、PASSWORD() 関数を使用する必要があります。

 
mysql> SET PASSWORD FOR jeffrey@"%" = PASSWORD('biscuit');

GRANT ... IDENTIFIED BY ステートメントまたは mysqladmin password コマンドを使用してパスワードを設定する場合、PASSWORD() 関数は必要ありません。両方ともパスワードを暗号化するので、以下のようにパスワードを 'biscuit' と指定します。

 
mysql> GRANT USAGE ON *.* TO jeffrey@"%" IDENTIFIED BY 'biscuit';

または

 
shell> mysqladmin -u jeffrey password biscuit

注意: PASSWORD() は、Unix のパスワード暗号化とは異なります。 「4.4.2 MySQL のユーザ名とパスワード」 節 参照 。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.4.9 パスワードのセキュリティ

自分のパスワードを他のユーザがわかるような方法で指定することは危険です。 クライアントプログラムを実行する際、パスワードの指定に使用できる方法を以下に示します。それぞれの危険度についても示します。

以上のことを総括すると、最も安全な方法は、クライアントプログラムにパスワードを要求させるか、適切に保護された `.my.cnf' ファイルにパスワードを指定することです。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.4.10 安全な接続の使用

4.4.10.1 基本概念   
4.4.10.2 必要条件   
4.4.10.3 MySQL での SSL 証明書の設定   
4.4.10.4 SSL GRANT オプション   
4.4.10.5 SSL コマンドラインオプション   

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.4.10.1 基本概念

バージョン 4.0.0 より、MySQL は SSL 暗号化接続をサポートしています。MySQL がどのように SSL を使用するか理解するには、SSL と X509 の基本概念が欠かせません。基本概念を理解している読者は、このセクションを読み飛ばしてください。

デフォルトでは、MySQL はクライアントとサーバ間で暗号化されていない接続を使用します。つまり、他人がすべてのトラフィックおよび送受信データを盗み見ることが可能な接続です。また、クライアントとサーバ間で転送中のデータを改ざんすることも可能です。公開ネットワークでの情報のやり取りでも安全性が求められる場合があります。そのような場合、暗号化されていない接続は適しません。

SSL とは、複数の異なる暗号化アルゴリズムを使用して、公開ネットワークで受信するデータの信頼性を保証するためのプロトコルです。データの変更、消失、および再生を検知するメカニズムがあります。SSL にはまた、X509 規格を使用する ID 認証を認識および提供するためのアルゴリズムも組み込まれています。

暗号化とは、データを読み取り不可能にする技術です。実際、今日の社会では、暗号化アルゴリズムによるさらなるセキュリティが求められています。暗号化メッセージの順番を変更したり同じデータを 2 回再生するなど、さまざまな種類の攻撃に対する耐性が必要となっています。

X509 とは、インターネット上で ID 認証を可能にする規格です。これは、電子商取引アプリケーションで最も一般的に使用されています。基本的には、"認証局" と呼ばれる会社が電子証明書を必要とする者に割り当てるという方法を取ります。証明書は、2 つの暗号化キー（公開キーと秘密キー）がある非対称暗号化アルゴリズムを使用しています。証明書の所有者は、他者に証明書を提示して自分の ID を証明します。証明書には、所有者の公開キーが含まれています。この公開キーで暗号化されたデータはすべて、対応する秘密キーがなければ解読できません。秘密キーは証明書の所有者が保持しています。

MySQL はデフォルトでは暗号化接続を使用しません。使用すると、クライアントとサーバのプロトコルがかなり遅くなるからです。どのような機能を追加した場合でもコンピュータには負荷がかかります。データの暗号化も例外ではなく、CPU を大幅に消費して時間がかかり、MySQL の主要タスクを遅らせる原因となります。そのためデフォルトでは、MySQL は速度が優先されています。

SSL、X509、および暗号化についてさらに詳細を知るには、インターネット検索エンジンを利用して必要な情報を検索してください。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.4.10.2 必要条件

安全な接続を MySQL で使用するには、以下を実行する必要があります。

  1. OpenSSL ライブラリをインストールする。OpenSSL 0.9.6 をインストールした MySQL はテスト済み。 http://www.openssl.org/ 。
  2. MySQL を --with-vio --with-openssl でコンフィギャする。
  3. 古い MySQL バージョンを使用している場合、mysql.user テーブルに新しい SSL 関連カラムを追加する必要がある。 この処理は、権限テーブルが MySQL 4.0.0 より前のバージョンの場合に必要となる。手順については 「2.5.6 権限テーブルのアップグレード」 を参照のこと。
  4. 実行中の mysqld サーバが OpenSSL をサポートしているかチェックするには、SHOW VARIABLES LIKE 'have_openssl' が YES を返すかどうかを確認する。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.4.10.3 MySQL での SSL 証明書の設定

以下、MySQL での SSL 証明書の設定例です。

 
DIR=`pwd`/openssl
PRIV=$DIR/private

mkdir $DIR $PRIV $DIR/newcerts
cp /usr/share/ssl/openssl.cnf $DIR
replace ./demoCA $DIR -- $DIR/openssl.cnf

# Create necessary files: $database, $serial and $new_certs_dir 
# directory (optional)

touch $DIR/index.txt
echo "01" > $DIR/serial

#
# Generation of Certificate Authority(CA)
#

openssl req -new -x509 -keyout $PRIV/cakey.pem -out $DIR/cacert.pem \
    -config $DIR/openssl.cnf

# Sample output:
# Using configuration from /home/monty/openssl/openssl.cnf
# Generating a 1024 bit RSA private key
# ................++++++
# .........++++++
# writing new private key to '/home/monty/openssl/private/cakey.pem'
# Enter PEM pass phrase:
# Verifying password - Enter PEM pass phrase:
# -----
# You are about to be asked to enter information that will be incorporated
# into your certificate request.
# What you are about to enter is what is called a Distinguished Name or a DN.
# There are quite a few fields but you can leave some blank
# For some fields there will be a default value,
# If you enter '.', the field will be left blank.
# -----
# Country Name (2 letter code) [AU]:FI
# State or Province Name (full name) [Some-State]:.
# Locality Name (eg, city) []:
# Organization Name (eg, company) [Internet Widgits Pty Ltd]:MySQL AB
# Organizational Unit Name (eg, section) []:
# Common Name (eg, YOUR name) []:MySQL admin
# Email Address []:

#
# Create server request and key
#
openssl req -new -keyout $DIR/server-key.pem -out \
    $DIR/server-req.pem -days 3600 -config $DIR/openssl.cnf

# Sample output:
# Using configuration from /home/monty/openssl/openssl.cnf
# Generating a 1024 bit RSA private key
# ..++++++
# ..........++++++
# writing new private key to '/home/monty/openssl/server-key.pem'
# Enter PEM pass phrase:
# Verifying password - Enter PEM pass phrase:
# -----
# You are about to be asked to enter information that will be incorporated
# into your certificate request.
# What you are about to enter is what is called a Distinguished Name or a DN.
# There are quite a few fields but you can leave some blank
# For some fields there will be a default value,
# If you enter '.', the field will be left blank.
# -----
# Country Name (2 letter code) [AU]:FI
# State or Province Name (full name) [Some-State]:.
# Locality Name (eg, city) []:
# Organization Name (eg, company) [Internet Widgits Pty Ltd]:MySQL AB
# Organizational Unit Name (eg, section) []:
# Common Name (eg, YOUR name) []:MySQL server
# Email Address []:
# 
# Please enter the following 'extra' attributes
# to be sent with your certificate request
# A challenge password []:
# An optional company name []:

#
# Remove the passphrase from the key (optional)
#

openssl rsa -in $DIR/server-key.pem -out $DIR/server-key.pem

#
# Sign server cert
#
openssl ca  -policy policy_anything -out $DIR/server-cert.pem \
    -config $DIR/openssl.cnf -infiles $DIR/server-req.pem

# Sample output:
# Using configuration from /home/monty/openssl/openssl.cnf
# Enter PEM pass phrase:
# Check that the request matches the signature
# Signature ok
# The Subjects Distinguished Name is as follows
# countryName           :PRINTABLE:'FI'
# organizationName      :PRINTABLE:'MySQL AB'
# commonName            :PRINTABLE:'MySQL admin'
# Certificate is to be certified until Sep 13 14:22:46 2003 GMT (365 days)
# Sign the certificate? [y/n]:y
# 
# 
# 1 out of 1 certificate requests certified, commit? [y/n]y
# Write out database with 1 new entries
# Data Base Updated

#
# Create client request and key
#
openssl req -new -keyout $DIR/client-key.pem -out \
    $DIR/client-req.pem -days 3600 -config $DIR/openssl.cnf

# Sample output:
# Using configuration from /home/monty/openssl/openssl.cnf
# Generating a 1024 bit RSA private key
# .....................................++++++
# .............................................++++++
# writing new private key to '/home/monty/openssl/client-key.pem'
# Enter PEM pass phrase:
# Verifying password - Enter PEM pass phrase:
# -----
# You are about to be asked to enter information that will be incorporated
# into your certificate request.
# What you are about to enter is what is called a Distinguished Name or a DN.
# There are quite a few fields but you can leave some blank
# For some fields there will be a default value,
# If you enter '.', the field will be left blank.
# -----
# Country Name (2 letter code) [AU]:FI
# State or Province Name (full name) [Some-State]:.
# Locality Name (eg, city) []:
# Organization Name (eg, company) [Internet Widgits Pty Ltd]:MySQL AB
# Organizational Unit Name (eg, section) []:
# Common Name (eg, YOUR name) []:MySQL user
# Email Address []:
# 
# Please enter the following 'extra' attributes
# to be sent with your certificate request
# A challenge password []:
# An optional company name []:

#
# Remove a passphrase from the key (optional)
#
openssl rsa -in $DIR/client-key.pem -out $DIR/client-key.pem

#
# Sign client cert
#

openssl ca  -policy policy_anything -out $DIR/client-cert.pem \
    -config $DIR/openssl.cnf -infiles $DIR/client-req.pem

# Sample output:
# Using configuration from /home/monty/openssl/openssl.cnf
# Enter PEM pass phrase:
# Check that the request matches the signature
# Signature ok
# The Subjects Distinguished Name is as follows
# countryName           :PRINTABLE:'FI'
# organizationName      :PRINTABLE:'MySQL AB'
# commonName            :PRINTABLE:'MySQL user'
# Certificate is to be certified until Sep 13 16:45:17 2003 GMT (365 days)
# Sign the certificate? [y/n]:y
# 
# 
# 1 out of 1 certificate requests certified, commit? [y/n]y
# Write out database with 1 new entries
# Data Base Updated

#
# Create a my.cnf file that you can use to test the certificates
#

cnf=""
cnf="$cnf [client]"
cnf="$cnf ssl-ca=$DIR/cacert.pem"
cnf="$cnf ssl-cert=$DIR/client-cert.pem"
cnf="$cnf ssl-key=$DIR/client-key.pem"
cnf="$cnf [mysqld]"
cnf="$cnf ssl-ca=$DIR/cacert.pem"
cnf="$cnf ssl-cert=$DIR/server-cert.pem"
cnf="$cnf ssl-key=$DIR/server-key.pem"
echo $cnf | replace " " '
' > $DIR/my.cnf

#
# To test MySQL

mysqld --defaults-file=$DIR/my.cnf &

mysql --defaults-file=$DIR/my.cnf

mysql-source-dist/SSL ディレクトリにあるデモ証明書を参照するように上記の `my.cnf' ファイルを修正することによっても、設定をテストできます。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.4.10.4 SSL GRANT オプション

MySQL は、通常のユーザ名とパスワードのスキームに加え、X509 証明書属性をチェックすることができます。通常のオプションもすべて必要です（ユーザ名、パスワード、IP アドレスマスク、データベース/テーブル名）。

接続の制限にはいくつかのシナリオがあります。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.4.10.5 SSL コマンドラインオプション

以下の表は、SSL、証明書ファイル、およびキーファイルの使用を指定するためのオプションをまとめたものです。 これらのオプションは MySQL 4.0 から導入されたものです。これらのオプションは、コマンドラインでもオプション設定ファイルでも使用できます。

--ssl
サーバに対しては、サーバが SSL 接続を許可するように指定する。 クライアントプログラムに対しては、SSL を使用してサーバに接続することを許可する。 このオプションだけでは SSL 接続の使用は保証されない。 --ssl-ca、--ssl-cert、および --ssl-key オプションも指定する必要がある。

注意: このオプションでは、SSL 接続が必須とならない。 たとえば、サーバまたはクライアントが SSL サポートなしでコンパイルされている場合、通常の暗号化されていない接続が使用される。

SSL 接続だけの使用を確実に保証するには、まず、GRANT ステートメントで REQUIRE SSL 節を含むアカウントをサーバに作成することが必要。 そしてこのアカウントを使用してサーバに接続する。このとき、サーバとクライアントの両方で SSL サポートが有効になっていることが必要である。

このオプションを使用して、接続に SSL を使用しないように指定することができる。 この場合、オプションを --skip-ssl または --ssl=0 として指定する。

--ssl-ca=file_name
信頼された SSL 認証局の一覧が含まれるファイルのパス。

--ssl-capath=directory_name
PEM 形式の信頼された CA 証明書が保存されているディレクトリのパス。

--ssl-cert=file_name
安全な接続を確立するために使用する SSL 証明書ファイルの名前。

--ssl-cipher=cipher_list
SSL 暗号化に使用できる暗号の一覧。 cipher_list は、openssl ciphers コマンドと同じ形式である。

例: --ssl-cipher=ALL:-AES:-EXP

--ssl-key=file_name
安全な接続を確立するために使用する SSL キーファイルの名前。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.5 障害の予防とリカバリ

4.5.1 データベースのバックアップ   
4.5.2 BACKUP TABLE 構文   
4.5.3 RESTORE TABLE 構文   
4.5.4 CHECK TABLE 構文   
4.5.5 REPAIR TABLE 構文   
4.5.6 myisamchk を使用したテーブルの保守とクラッシュのリカバリ   
4.5.7 テーブル保守計画   
4.5.8 テーブル情報の取得   

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.5.1 データベースのバックアップ

MySQL テーブルはファイルとして保存されるため、バックアップが簡単です。一貫したバックアップを行うには、そのテーブルに対して LOCK TABLES を実行してから、FLUSH TABLES を実行します。 「6.7.5 LOCK TABLES および UNLOCK TABLES 構文」 節 参照 。 「4.6.4 FLUSH 構文」 節 参照 。 読み取りロックだけが必要なので、データベースディレクトリのファイルをコピーしている間も、他のスレッドはテーブルに対してクエリを続行できます。FLUSH TABLE は、バックアップを開始する前に、キャッシュされているページをすべてディスクに書き込むために必要です。

3.23.56 から 4.0.12 では、セキュリティ上のリスクがあるため、BACKUP TABLE で既存ファイルの上書きはできないようになっています。

テーブルを SQL レベルでバックアップするには、SELECT INTO OUTFILE または BACKUP TABLE を使用します。 「6.4.1 SELECT 構文」 節 参照 。 「4.5.2 BACKUP TABLE 構文」 節 参照 。

データベースのバックアップには、mysqldump プログラムまたは mysqlhotcopy script を使用することもできます。 「4.9.7 mysqldump（テーブル構造とデータのダンプ）」 節 参照 。 「4.9.8 mysqlhotcopy（MySQL のデータベースとテーブルのコピー）」 節 参照 。

  1. データベースをフルバックアップする。

     
    shell> mysqldump --tab=/path/to/some/dir --opt db_name

または

shell> mysqlhotcopy db_name /path/to/some/dir

    サーバが何かを更新中でなければ、すべてのファイル（`*.frm'、`*.MYD'、および `*.MYI'）を単にコピーすることもできる。 スクリプト mysqlhotcopy はこの方法を使用している。 注意: データベースに InnoDB テーブルが含まれている場合、InnoDB はテーブルコンテンツをデータベースディレクトリに保存しないため、この方法は使用できない。mysqlhotcopy は MyISAM テーブルと ISAM テーブルにのみ有効。

  2. mysqld が実行中であればいったん停止し、--log-bin[=file_name] オプションで再起動する。 「4.10.4 バイナリログ」 節 参照 。 mysqldump 実行後に行われたデータの変更をレプリケートするための情報が、バイナリログファイルにより提供される。

MySQL サーバがスレーブの場合、どのバックアップ方法を選択しても、スレーブのデータをバックアップするとき、`master.info' ファイルと `relay-log.info' ファイルもバックアップしてください。これらのファイルは、スレーブのデータをリストア後、レプリケーションを再開するときに必要です。スレーブが、レプリケーションを行う LOAD DATA INFILE コマンドの対象となっていた場合、`SQL_LOAD-*' ファイルもバックアップしてください。このファイルは、--slave-load-tmpdir オプションによって指定されているディレクトリにあります（このファイルの場所が指定されていない場合、デフォルトで、この場所は tmpdir 変数の値になります）。中断されていた LOAD DATA INFILE 処理のレプリケーションを再開するためにスレーブはこれらのファイルを必要とします。

何かをリストアする必要がある場合、最初に REPAIR TABLE または myisamchk -r を使用してテーブルのリカバリを試みてください。ほとんどの場合、これで成功するはずです。myisamchk でリカバリできなかった場合、以下を実行します。これは、--log-bin で MySQL を起動している場合にのみ可能な方法です。 「4.10.4 バイナリログ」 を参照してください。

  1. オリジナルの mysqldump バックアップ、またはバイナリバックアップをリストアする。
  2. 以下のコマンドを実行して、バイナリログ内の更新を再実行する。

     
    shell> mysqlbinlog hostname-bin.[0-9]* | mysql

    場合に応じて、特定の位置から後のバイナリログだけを再実行する（通常は、リストアしたバックアップの日付以降の、不正なクエリ以外のすべてのバイナリログを再実行する）。 mysqlbinlog ユーティリティおよびその使用法の詳細については、 「4.9.5 mysqlbinlog（バイナリログからクエリを実行する）」 を参照のこと。

    更新ログ（MySQL 5.0 で廃止）を使用している場合、更新ログの内容を以下のように実行できる。

     
    shell> ls -1 -t -r hostname.[0-9]* | xargs cat | mysql

    ls は、すべての更新ログファイルを正しい順序で取得するために使用します。

SELECT * INTO OUTFILE 'file_name' FROM tbl_name で選択的バックアップを行い、LOAD DATA INFILE 'file_name' REPLACE ... でリストアすることもできます。重複テーブルを避けるため、テーブルに PRIMARY KEY または UNIQUE キーが必要です。REPLACE キーワードを使用すると、ユニークキーが新規レコードと旧レコードで重複していた場合に、旧レコードが新規レコードで置き換えられます。

バックアップに伴いパフォーマンス上の問題が発生する場合、レプリケーションをセットアップして、マスタではなくスレーブ上でバックアップを実行することによりこの問題を解決できる。 「4.11.1 はじめに」 節 参照 。

Veritas ファイルシステムを使用している場合、以下を実行できます。

  1. クライアント（または Perl）から、FLUSH TABLES WITH READ LOCK を実行する。

  2. 別のシェルから、mount vxfs snapshot を実行する。

  3. 最初のクライアントから、UNLOCK TABLES を実行する。

  4. スナップショットからファイルをコピーする。

  5. スナップショットのマウントを解除する。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.5.2 BACKUP TABLE 構文

 
BACKUP TABLE tbl_name[,tbl_name...] TO '/path/to/backup/directory'

ディスクにバッファされている変更をフラッシュした後で、テーブルをリストアするのに最低限必要な数のテーブルファイルをバックアップディレクトリにコピーします。現在のところ、このコマンドは MyISAM テーブルにのみ有効です。 MyISAM テーブルに対して、`.frm' 定義ファイルと `.MYD' データファイルをコピーします。これら 2 つのファイルからインデックスファイルを再度ビルドできます。

このコマンドを使用する前に、 「4.5.1 データベースのバックアップ」 を参照してください。

バックアップ中、各テーブルが処理されている間そのテーブルにのみ読み取りロックがかかります。複数のテーブルを 1 回のスナップショットでバックアップする場合は、まず LOCK TABLES を実行して、そのグループ内の各テーブルに対して読み取りロックをかけておく必要があります。

このコマンドは、以下のカラムで構成されるテーブルを返します。

カラム 値
Table テーブル名
Op 常に backup
Msg_type status、error、info、warning のいずれか
Msg_text メッセージ

注意: BACKUP TABLE は、MySQL バージョン 3.23.25 以降でのみ使用できます。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.5.3 RESTORE TABLE 構文

 
RESTORE TABLE tbl_name[,tbl_name...] FROM '/path/to/backup/directory'

BACKUP TABLE で作成されたバックアップから、1 つまたは複数のテーブルをリストアします。既存テーブルには上書きされません。既存テーブルの上にリストアしようとすると、エラーになります。インデックスを再度ビルドする必要があるため、リストアはバックアップよりも時間がかかります。キーが多ければ多いほど、時間がかかります。BACKUP TABLE と同じく、RESTORE TABLE は現在のところ、MyISAM テーブルにのみ有効です。

このコマンドは、以下のカラムで構成されるテーブルを返します。

カラム 値
Table テーブル名
Op 常に restore
Msg_type status、error、info、warning のいずれか
Msg_text メッセージ

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.5.4 CHECK TABLE 構文

 
CHECK TABLE tbl_name[,tbl_name...] [option [option...]]

option = QUICK | FAST | MEDIUM | EXTENDED | CHANGED

CHECK TABLE は、MyISAM テーブルと InnoDB テーブルにのみ有効です。MyISAM テーブルの場合、このテーブルで myisamchk --medium-check table_name を実行するのと同じです。

オプションを何も指定しなければ、MEDIUM が使用されます。

1 つまたは複数のテーブルのエラーをチェックします。MyISAM テーブルでは、キー統計が更新されます。このコマンドは、以下のカラムで構成されるテーブルを返します。

カラム 値
Table テーブル名
Op 常に check
Msg_type status、error、info、warning のいずれか
Msg_text メッセージ

注意: このステートメントは、チェックした各テーブルに関する多くの情報レコードを生成します。 正常な場合、Msg_type は status で、Msg_text は通常 OK になります。 OK または Table is already up to date が得られなければ、テーブルの修復が必要と考えられます。 「4.5.6 myisamchk を使用したテーブルの保守とクラッシュのリカバリ」 節 参照 。 Table is already up to date は、テーブルのストレージマネージャが、そのテーブルにチェックが必要ないと判断したことを意味します。

以下のチェックタイプがあります。

タイプ 意味
QUICK 不正リンクをチェックするためのレコードスキャンを実行しない。
FAST 正しく閉じられなかったテーブルだけをチェックする。
CHANGED 前回のチェック後に変更されたテーブルと、正しく閉じられなかったテーブルだけをチェックする。
MEDIUM レコードをスキャンして、削除されたリンクが問題なかったことを確認する。また、レコードのキーチェックサムを計算し、キーの計算されたチェックサムを使って確認する。
EXTENDED 各レコードですべてのキーの完全キールックアップを実行する。テーブルの整合性が 100% 保証されるが、時間がかかる。

動的サイズの MyISAM テーブルでは、チェックが開始された場合、常に MEDIUM チェックが実行されます。静的サイズのレコードは破損していることが非常にまれなので、QUICK および FAST でレコードスキャンをスキップします。

チェックオプションは以下のように組み合わせることができます。以下の例では、テーブルが正しく閉じられたかどうかを確認するクイックチェックを行います。

 
CHECK TABLE test_table FAST QUICK;

注意: 場合によっては CHECK TABLE はテーブルを変更します。これは、テーブルに 'corrupted' または 'not closed properly' というマークがあるのに、CHECK TABLE がテーブル内に問題を発見しなかった場合に発生します。この場合、CHECK TABLE はテーブルを OK とマークします。

テーブルが破損している場合、データ部分よりもインデックスに問題のある方が可能性が高いです。上記のチェックタイプはいずれも、インデックスを完全にチェックするのでほとんどのエラーは発見できます。

問題がないと思われるテーブルをチェックする場合、チェックオプションを使用しないか、または QUICK オプションを使用します。QUICK は、急いでいるとき、およびデータファイルのエラーが見逃されるかもしれないという非常に小さな危険性を無視できる場合に使用します。ほとんどの場合、MySQL は通常どおりに使用していれば、データファイルのエラーを発見します。発見した場合、そのテーブルには 'corrupted' のマークが付き、修復するまでそのテーブルは使用できません。

FAST および CHANGED は、テーブルをときどきチェックしたい場合に、スクリプトから（たとえば cron から）実行されることを想定しています。通常は、CHANGED よりも FAST の方を使用してください（これが当てはまらないのは、MyISAM コード内にバグが疑われる場合のみです）。

EXTENDED は、通常のチェック後に、MySQL がレコードを更新したりキーでレコードを検索しようとした際に、不自然なエラーが発生する場合にのみ使用します（通常のチェックが正常に終了した後でエラーが発生するのは非常にまれなことです）。

CHECK TABLE で報告される問題の中には、自動的に修正されないものがあります。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.5.5 REPAIR TABLE 構文

 
REPAIR [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_name[,tbl_name...] [QUICK] [EXTENDED] [USE_FRM]

REPAIR TABLE は MyISAM テーブルにのみ有効であり、このテーブルで myisamchk -r table_name を実行するのと同じです。

通常であれば、このコマンドを使用することはありませんが、障害が発生した場合、REPAIR TABLE を使用すれば、ほとんどの場合、MyISAM テーブルのすべてのデータを取り戻せます。テーブルが頻繁に破損するようであれば、その原因を突き止めて、REPAIR TABLE を使用する必要がなくなるようにしてください。 「A.4.1 MySQL が何度もクラッシュする場合に行うこと」 節 参照 。 「7.1.3 MyISAM テーブルの問題」 節 参照 。

REPAIR TABLE は、破損した可能性のあるテーブルを修復します。このコマンドは、以下のカラムで構成されるテーブルを返します。

カラム 値
Table テーブル名
Op 常に repair
Msg_type status、error、info、warning のいずれか
Msg_text メッセージ

注意: このステートメントは、修復した各テーブルに関する多くの情報レコードを生成します。 正常な場合、Msg_type は status で、Msg_text は通常 OK になります。OK を得られない場合は、myisamchk --safe-recover でテーブルの修復を試みてください。REPAIR TABLE ではまだ myisamchk のすべてのオプションをカバーしていません。将来は、このコマンドをより柔軟性の高いものにする予定です。

QUICK を指定した場合、REPAIR TABLE はインデックスツリーだけを修復しようとします。

EXTENDED を使用すると、MySQL はソートごとにインデックスを生成するのではなく、レコードごとにインデックスを生成します。確実に圧縮される長い CHAR キーを使用している場合など、固定長キーをソートするよりこの方法の方が適しています。このタイプの修復は、myisamchk --safe-recover で実行される修復とほぼ同じです。

MySQL 4.0.2 から、REPAIR に USE_FRM モードが導入されています。 `.MYI' ファイルがない、またはそのヘッダが破損している場合にこのモードを使用します。 このモードでは、`.frm' ファイルの情報を使用してテーブルが再度作成されます。このような修復は、myisamchk ではできません。

警告: REPAIR TABLE を実行中に mysqld が終了してしまった場合、他のコマンドを実行する前にもう 1 回 REPAIR を必ず実行してください（もちろん、常にバックアップから開始することを推奨します）。最悪の場合、データファイルに関する情報がない新規のクリーンなインデックスファイルができることがあり、次のコマンドでデータファイルが上書きされてしまう可能性があります。これはあまりないことではありますが、可能性としてはあり得るので、注意が必要です。

MySQL 4.1.1 より前では、REPAIR コマンドはバイナリログに書き込まれません。MySQL 4.1.1 以降、任意の NO_WRITE_TO_BINLOG キーワード（またはそのエイリアスの LOCAL）を使用しない限り、このコマンドはバイナリログに書き込まれます。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.5.6 myisamchk を使用したテーブルの保守とクラッシュのリカバリ

MySQL バージョン 3.23.13 以降、CHECK TABLE コマンドを使用して MyISAM テーブルをチェックできるようになりました。 「4.5.4 CHECK TABLE 構文」 節 参照 。 テーブルの修復には REPAIR TABLE コマンドを使用できます。 「4.5.5 REPAIR TABLE 構文」 節 参照 。

MyISAM テーブル（`.MYI' および `.MYD'）のチェックおよび修復には myisamchk ユーティリティを使用してください。ISAM テーブル（`.ISM' および `.ISD'）のチェックおよび修復には isamchk ユーティリティを使用します。 「7. MySQL のテーブル型」 節 参照 。

以下の説明は myisamchk についてですが、旧 isamchk にもすべて当てはまります。

myisamchk ユーティリティを使用して、データベーステーブルの情報を取得したり、テーブルのチェック、修復、および最適化を実行できます。以下のセクションでは、myisamchk の起動方法（オプションの説明も含む）、テーブル保守のスケジュール、およびさまざまな myisamchk 機能について説明します。

多くの場合、OPTIMIZE TABLES コマンドを使用してテーブルの最適化と修復を行うこともできますが、myisamchk に比べると時間がかかり、重大エラーの場合は信頼性も高くありません。その反面、OPTIMIZE TABLE は使用が簡単で、テーブルのフラッシュを心配する必要がありません。 「4.6.1 OPTIMIZE TABLE 構文」 節 参照 。

myisamchk による修復は信頼性に優れていますが、修復を実行する（つまりテーブルに多くの変更を加える）前に、バックアップを作成しておくことが必要です。

4.5.6.1 myisamchk 起動構文   
4.5.6.2 myisamchk の一般的なオプション   
4.5.6.3 myisamchk のチェックオプション   
4.5.6.4 myisamchk の修復オプション   
4.5.6.5 myisamchk のその他のオプション   
4.5.6.6 myisamchk のメモリ使用   
4.5.6.7 myisamchk を使用したクラッシュのリカバリ   
4.5.6.8 テーブルのエラーチェック方法   
4.5.6.9 テーブルの修復方法   
4.5.6.10 テーブルの最適化   

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.5.6.1 myisamchk 起動構文

myisamchk は以下のように起動します。

 
shell> myisamchk [options] tbl_name

options は、myisamchk が実行することを指定します。それらについてはここで説明します（myisamchk --help を実行すると、オプションの一覧を取得できます）。オプションを指定しなければ、myisamchk はテーブルのチェックだけを行います。詳細情報を取得したり、myisamchk に修正を実行させるには、ここで説明するオプションを指定することが必要です。

tbl_name は、チェックおよび修復対象となるデータベーステーブル名です。データベースディレクトリ以外の場所で myisamchk を実行する場合、myisamchk に対してファイルのパスを指定する必要があります。実際、myisamchk は処理対象のファイルがデータベースディレクトリにあるかどうかを問題にしません。データベーステーブルのファイルを他の場所にコピーし、そこでリカバリ操作を実行することもできます。

myisamchk コマンドラインに複数のテーブル名を指定することもできます。また、インデックスファイル名（`.MYI' サフィックス付き）を指定することもできます。`*.MYI' パターンを使用すれば 1 つのディレクトリ内のすべてのテーブルを指定することができます。 たとえば、カレントディレクトリがデータベースディレクトリである場合、以下のようにすればディレクトリ内の全テーブルをチェックできます。

 
shell> myisamchk *.MYI

カレントディレクトリがデータベースディレクトリでない場合、以下のようにディレクトリのパスを指定することにより、その全テーブルをチェックできます。

 
shell> myisamchk /path/to/database_dir/*.MYI

MySQL データディレクトリのパスにワイルドカードを使用することにより、全データベースのすべてのテーブルをチェックすることもできます。

 
shell> myisamchk /path/to/datadir/*/*.MYI

すべてのテーブルに対して簡単にチェックを行う場合、以下の方法を推奨します。

 
myisamchk --silent --fast /path/to/datadir/*/*.MYI
isamchk --silent /path/to/datadir/*/*.ISM

すべてのテーブルをチェックし、破損していたテーブルをすべて修復するには、以下を実行します。

 
myisamchk --silent --force --fast --update-state -O key_buffer=64M \
          -O sort_buffer=64M -O read_buffer=1M -O write_buffer=1M \
          /path/to/datadir/*/*.MYI
isamchk --silent --force -O key_buffer=64M -O sort_buffer=64M \
        -O read_buffer=1M -O write_buffer=1M /path/to/datadir/*/*.ISM

この例では、64 メガバイト以上の空き容量があることを前提にしています。

注意: 以下のエラーが発生する場合があります。

 
myisamchk: warning: 1 clients is using or hasn't closed the table properly

これは、他のプログラム（mysqld サーバなど）によって更新されてまだ閉じられていないファイル、または正しく閉じられていないファイルのテーブルをチェックしようとしているということです。

mysqld を実行中であれば、FLUSH TABLES ですべてのテーブルの同期とクローズを強制的に実行し、myisamchk を実行する間は他のだれにもテーブルを使用させないようにしてください。MySQL バージョン 3.23 で、この問題を回避する最も簡単な方法は、myisamchk の代わりに CHECK TABLE を使用してテーブルをチェックすることです。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.5.6.2 myisamchk の一般的なオプション

myisamchk は、以下のオプションをサポートします。

-# または --debug=debug_options
デバッグログを出力する。debug_options 文字列には、'd:t:o,filename' がよく使用される。
-? または --help
ヘルプメッセージを表示して終了する。
-O name=value, --set-variable=name=value
変数の値を指定する。 注意: --set-variable=name=value および -O name=value 構文は MySQL 4.0 で廃止。代わりに --name=value を使用すること。 myisamchk で使用できる変数とそのデフォルト値は、myisamchk --help で確認できる。
変数 値
key_buffer_size 523264
read_buffer_size 262136
write_buffer_size 262136
sort_buffer_size 2097144
sort_key_blocks 16
decode_bits 9

sort_buffer_size は、キーのソートによってキーが修復された場合に使用する。これは、--recover を使用すると通常発生する状態。

key_buffer_size は、--extended-check を使用してテーブルをチェックしている場合や、通常の挿入と同様、キーをテーブルのレコードごとに挿入することによりキーが修復される場合に使用する。以下の場合に、キーバッファによる修復が使用される。

キーバッファによる修復は、ソートによる修復よりディスク領域は少なくて済むが、処理速度は遅くなる。

速い修復を望む場合は、上記の変数を利用可能メモリの 1/4 に設定する。上記バッファは 1 度に 1 つだけ使用されるため、両方の変数を大きな値に設定できる。

-s または --silent
サイレントモード。エラー発生時のみ出力する。-s を 2 回指定すると（-ss）、myisamchk はさらに出力が少なくなる。
-v または --verbose
冗長モード。詳細情報を出力する。-d および -e と併用できる。-v を複数回指定すると（-vv、-vvv など）、より冗長になる。
-V または --version
myisamchk のバージョン情報を出力して終了する。
-w または --wait
テーブルがロックされている場合にエラーを出さず、テーブルのロックが解除されるまで待機する。注意: そのテーブルに対して --skip-external-locking オプション付きの mysqld が実行している場合、そのテーブルは別の myisamchk コマンドによってのみロックされる。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.5.6.3 myisamchk のチェックオプション

-c または --check
テーブルのエラーをチェックする。myisamchk に対して明示的にこのオプションを上書きするオプションを指定しなければ、これがデフォルト処理になる。

-e または --extend-check
テーブルを完全にチェックする（インデックスが多い場合、処理時間がかかる）。このオプションは、極端な場合にだけ使用する。通常、myisamchk または myisamchk --medium-check でテーブルのエラーを検出できる。

--extended-check を使用し、メモリが豊富にある場合、key_buffer_size の値を大きく設定すべきである。

-F または --fast
正しく閉じられなかったテーブルだけをチェックする。
-C または --check-only-changed
前回のチェック以降に変更されたテーブルだけをチェックする。
-f または --force
myisamchk でテーブルにエラーが検出された場合、myisamchk を -r（修復）で再起動する。
-i または --information
チェックしたテーブルの統計を出力する。
-m または --medium-check
extended-check よりも速いが、すべてのエラーは見つけられない。 しかし、ほとんどの場合はこれで十分である。
-U または --update-state
テーブルをいつチェックしたか、その際テーブルが破損していたかどうかを `.MYI' ファイルに記録する。このオプションは、--check-only-changed オプションを最大限有効に活用するために使用する。ただし、mysqld サーバがそのテーブルを使用しており、mysqld を --skip-external-locking で実行している場合は、このオプションを使用してはいけない。
-T または --read-only
テーブルにチェック済みのマーキングをしない。mysqld --skip-external-locking などのような、ロックを使用しない他のアプリケーションによって使用されているテーブルを、myisamchk を使用してチェックする場合、このオプションが便利である。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.5.6.4 myisamchk の修復オプション

以下のオプションは、myisamchk を -r または -o で起動した場合に使用できます。

-B または --backup
`.MYD' ファイルのバックアップを `filename-time.BAK' として作成する。
--correct-checksum
テーブルのチェックサム情報を修正する。
-D # または --data-file-length=#
データファイルの最大長（データファイルが 'full' で再生成されるとき）。
-e または --extend-check
データファイルから可能なすべてのレコードのリカバリを試みる。 通常、このオプションではガーベジレコードも多く見つかる。他に手がないとき以外は、このオプションは使用しないようにする。
-f または --force
停止しないで、古いテンポラリファイル（`table_name.TMD'）を上書きする。
-k # または --keys-used=#
ISAM を使用している場合、ISAM ストレージエンジンが最初の # インデックスだけを更新するように指定する。MyISAM を使用している場合は、各バイナリビットが 1 つのキーに対応しているので、どのキーを使用するかはビット計算をして指定する。 このオプションを使用して、挿入を高速化できる。無効化されたインデックスを再び有効にするには、myisamchk -r を使用する。
-l または --no-symlinks
シンボリックリンクを使用しない。通常、myisamchk はシンボリックリンクが指すテーブルを修復する。このオプションは MySQL 4.0 にはない。MySQL 4.0 では修復中にシンボリックリンクが削除されないためである。
-p または --parallel-recover
-r および -n と同じテクニックを使用するが、すべてのキーを複数のスレッドで並列処理する。 このオプションは MySQL 4.0.2 で導入。 これは、アルファコードである。使用にはリスクが伴う。
-r または --recover
ほとんどのエラーを修復できる。ただし、ユニークキーが一意でないエラーの場合には対応できない（ISAM テーブルまたは MyISAM テーブルでは非常に珍しいエラーである）。 テーブルをリカバリする場合は、まずこのオプションを試す。-r ではテーブルをリカバリできないと myisamchk により報告された場合のみ、-o を実行する。注意: めったにないことではあるが -r が失敗した場合でも、データファイルは損傷を受けない。 メモリが豊富にある場合は、sort_buffer_size のサイズを大きくすべきである。
-o または --safe-recover
古いリカバリ方式を使用する（すべてのレコードを順番どおりに読み取り、検出されたレコードに基づいてすべてのインデックスツリーを更新する）。これは -r よりもかなり遅いが、-r で処理できない場合にも対応する。このリカバリ方式は、-r よりもディスク容量の使用が少なくて済む。通常は最初に -r で修復を試みて、それに失敗した場合のみ -o を使用する。

メモリが豊富にある場合は、key_buffer_size のサイズを大きくすべきである。

-n または --sort-recover
テンポラリファイルが非常に大きい場合でも、キー解決のために myisamchk にソートを強制する。

--character-sets-dir=...
キャラクタセットが格納されているディレクトリ。
--set-character-set=name
インデックスによって使用されるキャラクタセットを変更する。
-t または --tmpdir=path
テンポラリファイルを保存するパス。これを設定しない場合、myisamchk はこれに環境変数 TMPDIR を使用する。 MySQL 4.1 以降、tmpdir で、複数のパスをコロン : で区切って設定できるようになっている（Windows ではセミコロン ;）。これは、ラウンドロビン方式で使用される。
-q または --quick
データファイルを修正しないことにより、修復を速く行う。-q を 2 回指定すると、重複キーの場合に、myisamchk にオリジナルのデータファイルの修正を強制する。
-u または --unpack
myisampack でパックされたファイルをアンパックする。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.5.6.5 myisamchk のその他のオプション

以下は、myisamchk で実行できる、テーブルの修復およびチェック以外の操作です。

-a または --analyze
キーの分布を分析する。このオプションを使用することにより、結合オプティマイザが、テーブルの結合順序や使用すべきキーをより的確に判断できるようになるため、結合パフォーマンスが向上する。 myisamchk --describe --verbose table_name' または MySQL で SHOW KEYS を使用することにより、キーの分布を確認できる。
-d または --description
テーブルに関する情報を出力する。
-A または --set-auto-increment[=value]
指定の値以上で AUTO_INCREMENT を開始する。ここで値を指定しなければ、次の AUTO_INCREMENT 値は、オートキーに使用された最高値に 1 を加えた値になる。
-S または --sort-index
インデックスツリーブロックを降順にソートする。 検索が最適化され、キーによるテーブルスキャンが速くなる。
-R または --sort-records=#
インデックスに従ってレコードをソートする。このソートにより、データが整理され、このインデックスでの SELECT や ORDER BY の処理速度が速くなる（最初のソートは非常に遅くなる）。 テーブルのインデックス番号を調べるには SHOW INDEX を使用する。テーブルのインデックスが myisamchk が検出する順序で表示される。インデックス番号は 1 から始まる。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.5.6.6 myisamchk のメモリ使用

myisamchk を実行する場合、メモリの配分が重要な問題になります。 myisamchk は、-O オプションで指定したサイズ以上のメモリは使用しません。非常に大きなファイルに対して myisamchk を使用する場合、メモリの使用量を最初に決めておいてください。修復処理に使用するメモリのデフォルト値は約 3 メガバイトです。大きな値を使用すれば、myisamchk の処理を高速化できます。たとえば、32 メガバイト以上の RAM がある場合、以下のようにオプションを指定できます（必要に応じて他のオプションも追加します）。

 
shell> myisamchk -O sort=16M -O key=16M -O read=1M -O write=1M ...

ほとんどの場合、-O sort=16M で十分です。

myisamchk は、TMPDIR のテンポラリファイルを使用することに注意してください。TMPDIR がメモリファイルシステムをポイントしていれば、すぐにメモリ不足エラーになります。このエラーが発生する場合には、TMPDIR を、容量の大きいディレクトリを指すように設定し、myisamchk を再起動します。

修復時も、myisamchk は大きなディスク容量を必要とします。

修復中にディスク容量に関する問題が発生した場合は、--recover の代わりに --safe-recover を使用できます。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.5.6.7 myisamchk を使用したクラッシュのリカバリ

mysqld を --skip-external-locking で実行している場合（Linux などのシステムではデフォルト）、mysqld が使用している同じテーブルを myisamchk でチェックしても信頼できません。myisamchk の実行中、mysqld からテーブルにアクセスするユーザが確実にない場合のみ、mysqladmin flush-tables を実行してからテーブルをチェックします。テーブルにアクセスするユーザがいるかどうか確信できない場合には、テーブルをチェックする間、mysqld を停止する必要があります。mysqld がテーブルを更新しているときに myisamchk を実行すると、テーブルが破損していない場合でも破損の警告が出る可能性があります。

--skip-external-locking を使用していなければ、いつでも myisamchk を使用してテーブルをチェックできます。この間、テーブルを更新しようとするクライアントはすべて、myisamchk の準備が整うのを待ってから実行します。

myisamchk を使用してテーブルを修復または最適化する場合、必ず、mysqld サーバがそのテーブルを使用していないことを確認してください（--skip-external-locking を使用している場合も同様です）。 mysqld を停止しない場合は、少なくとも mysqladmin flush-tables を myisamchk の前に実行してください。 サーバと myisamchk が同時にテーブルにアクセスすると、テーブルが破損するおそれがあります。

この章では、MySQL データベースのデータ破損のチェック方法およびその対処方法について説明します。テーブルが頻繁に破損する場合は、原因を突き止める必要があります。 「A.4.1 MySQL が何度もクラッシュする場合に行うこと」 節 参照 。

MyISAM テーブルのセクションで、テーブルが破損する原因を示しています。 「7.1.3 MyISAM テーブルの問題」 節 参照 。

クラッシュをリカバリする際には、データベース内のテーブル tbl_name のそれぞれがデータベースディレクトリ内の次の 3 つのファイルに対応していることを理解しておく必要があります。

ファイル 用途
`tbl_name.frm' テーブル定義ファイル
`tbl_name.MYD' データファイル
`tbl_name.MYI' インデックスファイル

これら 3 つのファイルタイプはいずれもさまざまな形で破損する可能性がありますが、特にデータファイルとインデックスファイルに問題がよく発生します。

myisamchk は、`.MYD'（データ）ファイルのコピーをレコードごとに生成します。修復の最終段階で古い `.MYD' ファイルを削除し、新規ファイルをオリジナルの名前に変更します。--quick を使用している場合、myisamchk はテンポラリ `.MYD' ファイルを生成しませんが、代わりに `.MYD' ファイルが正常であるとみなし、`.MYD' ファイルに手を加えずに新規インデックスファイルだけを生成します。`.MYD' ファイルに問題があった場合は myisamchk が自動的に検知して修復を中止するため、この方法も安全です。2 つの --quick オプションを myisamchk に設定することもできます。この場合、myisamchk はいくつかのエラー（重複キーなど）でも中止せず、`.MYD' ファイルを修正して解決しようとします。通常の修復処理にディスクの空き容量では足りない場合にのみ、2 つの --quick オプション指定が役立ちます。この場合、少なくとも myisamchk を実行する前にバックアップを作成しておいてください。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.5.6.8 テーブルのエラーチェック方法

MyISAM テーブルをチェックするには、以下のコマンドを使用します。

myisamchk tbl_name
これで、エラーのほとんどは発見できる。これで発見できないエラーは、データファイルだけに関連する破損である（これは非常にまれ）。テーブルをチェックする場合、通常、myisamchk をオプションなしか、-s または --silent のオプションで実行する。

myisamchk -m tbl_name
これで、エラーのほとんどは発見できる。このコマンドを実行すると、最初にすべてのインデックスエントリのエラーがチェックされ、次にすべてのレコードが読み込まれる。レコードのすべてのキーのチェックサムが計算され、その結果がインデックスツリーのキーのチェックサムと一致するかどうか確認される。

myisamchk -e tbl_name
このコマンドを実行すると、すべてのデータの完全なチェックが行われる（-e は "extended check" のこと）。各レコードのすべてのキーが読み取られ、チェックされ、正しいレコードが指されているか確認される。この操作は、多くのキーがある大きなテーブルでは時間がかかる。myisamchk は通常、最初のエラーが見つかった時点で停止する。詳細情報を得るには、--verbose（-v）オプションを追加する。これにより、myisamchk は最大 20 のエラーが検出されるまで処理を続行する。 通常は、テーブル名以外の引数を指定しない myisamchk だけで十分である。

myisamchk -e -i tbl_name
前のコマンドと似ているが、-i オプションによって myisamchk が統計情報も出力する。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.5.6.9 テーブルの修復方法

このセクションでは、MyISAM テーブル（`.MYI' および `.MYD' の拡張子）に対して myisamchk を使用する方法について説明します。ISAM テーブル（`.ISM' および `.ISD' の拡張子）に対しては、isamchk を使用してください。

MySQL バージョン 3.23.14 以降、REPAIR TABLE コマンドで MyISAM テーブルを修復できるようになっています。 「4.5.5 REPAIR TABLE 構文」 節 参照 。

テーブル破損の症状としては、クエリが予期せず中断したり、以下のようなエラーが発生します。

他の場合についてはテーブルを修復する必要があります。通常は、myisamchk でほとんどのエラーを検出して修復できます。

修復プロセスは、以下説明するように 4 段階で構成されます。開始する前に、データベースディレクトリに移動（cd）してテーブルファイルのアクセス権を確認してください。mysqld を実行する Unix ユーザに読み取り権限があることを確認します（この確認を行うユーザにもこれらのファイルへのアクセス権が必要）。ファイルを修正する必要がある場合は、書き込み権限も必要です。

MySQL バージョン 3.23.16 以降を使用している場合は、CHECK コマンドと REPAIR コマンドを使用して MyISAM テーブルのチェックおよび修復を実行できます（できるだけ、これらのコマンドを使用してください）。 「4.5.4 CHECK TABLE 構文」 節 参照 。 「4.5.5 REPAIR TABLE 構文」 節 参照 。

テーブル保守に関するセクションで、isamchk および myisamchk のオプションを説明しています。 「4.5.6 myisamchk を使用したテーブルの保守とクラッシュのリカバリ」 節 参照 。

これらのコマンドで失敗した場合、または isamchk および myisamchk の拡張機能を使用する場合につき、以下の説明を参考にして修復作業を行ってください。

コマンドラインを使用してテーブルを修復する場合、まず、mysqld サーバをシャットダウンする必要があります。注意: mysqladmin shutdown をリモートサーバから実行した場合、mysqladmin が戻ってもしばらくの間、mysqld サーバはシャットダウンしません。すべてのクエリが停止してすべてのキーがディスクにフラッシュされた時点でシャットダウンします。

段階 1: テーブルのチェック

myisamchk *.MYI または時間に余裕があれば myisamchk -e *.MYI を実行します。-s（サイレント）オプションを使用すると、不要な情報は出力されません。

mysqld サーバが終了している場合、--update オプションを使用して myisamchk がテーブルに 'checked' のマークを付けるようにします。

myisamchk がエラーを返したテーブルだけ、修復する必要があります。そのようなテーブルについては、段階 2 へ進みます。

チェック時に複雑なエラー（out of memory エラーなど）が発生した場合、あるいは myisamchk がクラッシュした場合は段階 3 に進みます。

段階 2: 簡単で安全な修復

注意: 修復を速く行うには、-O sort_buffer=# -O key_buffer=#（# は利用可能メモリの約 4 分の 1）をすべての isamchk/myisamchk コマンドに追加します。

最初に myisamchk -r -q tbl_name（-r -q は "クイックリカバリモード" の意）を実行します。これにより、データファイルを変更せずにインデックスファイルの修復だけが行われます。データファイルにあるべきものがすべてあり、削除リンクがデータファイル内の正しい場所を指していれば、テーブルは正常に修復されます。成功したら、次のテーブルの修復を開始します。失敗した場合は以下の手順を実行します。

  1. まず、データファイルのバックアップを作成する。

  2. myisamchk -r tbl_name（-r は "リカバリモード" の意）を使用する。これにより、不正なレコードと削除されたレコードがデータファイルから削除され、インデックスファイルが再構築される。

  3. 前のステップが失敗した場合、myisamchk --safe-recover tbl_name を使用する。 セーフリカバリモードにより、古いリカバリ形式が使用され、通常のリカバリモードでは処理できない修復が行われる。ただし、時間がかかる。

修復時に複雑なエラー（out of memory エラーなど）が発生した場合、あるいは myisamchk がクラッシュした場合は段階 3 に進みます。

段階 3:困難な修復

インデックスファイルの最初の 16K ブロックが破損または不正な情報を含む場合、あるいはインデックスファイルがない場合だけ、この段階に進みます。この段階では、新しいインデックスファイルを作成する必要があります。以下を実行してください。

  1. データファイルを安全な場所に移動する。

  2. テーブル記述ファイルを使用して、新しい（空白の）データとインデックスファイルを作成する。

     
    shell> mysql db_name
mysql> SET AUTOCOMMIT=1;
mysql> TRUNCATE TABLE table_name;
mysql> quit

    使用している SQL バージョンに TRUNCATE TABLE がない場合は、代わりに DELETE FROM table_name を使用する。

  3. 古いデータファイルを、新しく作成したデータファイルにコピーする （単に古いファイルを新しいファイルに移動するのではなく、万一に備えて元の場所にも残しておく）。

段階 2 に戻ります。これで、myisamchk -r -q が機能するはずです（無限ループにならないはずです）。

MySQL 4.0.2 より、この手順全体を自動で実行する REPAIR ... USE_FRM も使用できるようになりました。

段階 4: 非常に困難な修復

記述ファイルもクラッシュしている場合にのみこの段階に進みます。ただし、テーブル作成後に記述ファイルが変更されることはないので、通常は発生しない状況です。

  1. バックアップから記述ファイルをリストアし、段階 3 に戻る。インデックスファイルをリストアして段階 2 に戻ることもできる。後者の場合、myisamchk -r を実行する。

  2. バックアップがない場合でも、テーブルがどのように作成されたか正確にわかっていれば、別のデータベースにテーブルのコピーを作成する。テーブルのコピーを作成したデータベースから、新しいデータファイルを削除し、記述ファイルとインデックスファイルを、クラッシュしたデータベースに移動する。これで新しい記述ファイルとインデックスファイルができ、データファイルは前のものがそのまま残る。段階 2 に戻り、インデックスファイルを再構築する。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.5.6.10 テーブルの最適化

断片化したレコードを結合したり、レコードの削除または更新によって発生した無駄なスペースを除去するには、myisamchk をリカバリモードで実行します。

 
shell> myisamchk -r tbl_name

同様に、SQL の OPTIMIZE TABLE ステートメントを使用して、テーブルを最適化することもできます。OPTIMIZE TABLE はテーブルの修復とキー分析を行い、さらにインデックスツリーをソートして、キー走査の処理速度を上げます。 また、OPTIMIZE TABLE を使用した場合、サーバ側ですべての処理が行われるため、ユーティリティとサーバ間で不要なやり取りが発生しません。 「4.6.1 OPTIMIZE TABLE 構文」 節 参照 。

myisamchk には、テーブルのパフォーマンスを向上させるためのオプションが数多く用意されています。

オプションの詳細な説明については、 「4.5.6.1 myisamchk 起動構文」 節 参照 を参照してください。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.5.7 テーブル保守計画

MySQL バージョン 3.23.13 以降、CHECK TABLE コマンドを使用して MyISAM テーブルをチェックできるようになりました。 「4.5.4 CHECK TABLE 構文」 節 参照 。 テーブルの修復は REPAIR TABLE コマンドで行えます。 「4.5.5 REPAIR TABLE 構文」 節 参照 。

問題が発生するのを待つより、定期的にテーブルチェックを行うことを推奨します。保守目的では、myisamchk -s を使用してテーブルをチェックできます。-s オプション（--silent の短縮形）を使用すると、サイレントモードで myisamchk が実行され、エラー発生時のみメッセージが出力されます。

また、サーバが起動するたびにテーブルをチェックするという方法もあります。 たとえば、更新の途中でマシンがリブートされた場合、影響を受けた可能性のあるテーブルをすべてチェックする必要があります（つまり、"破損の可能性があるテーブル" をチェックします）。リブート後に古い `.pid'（プロセス ID）ファイルが残っていた場合、mysqld_safe にテストを追加して、直前の 24 時間以内に変更されたテーブルのチェックを myisamchk で実行することができます。`.pid' ファイルは mysqld 起動時に作成され、正常終了時に削除されます。システム起動時に `.pid' ファイルが存在していれば、mysqld が異常終了したことになります。

より完全なテストを行うには、`.pid' ファイルの作成後に変更されたすべてのテーブルをチェックするという方法もあります。

通常のシステム運用中にも定期的にテーブルをチェックしてください。MySQL AB では、週に一度 cron ジョブを実行して重要なテーブルをチェックしています。`crontab' ファイルは以下のようになります。

 
35 0 * * 0 /path/to/myisamchk --fast --silent /path/to/datadir/*/*.MYI

これで、クラッシュしたテーブルに関する情報が出力されるので、必要に応じて検査および修復を行えます。

ここ数年、予想外のテーブル破損（ハードウェアトラブル以外による破損）は発生していないので、当社では週に一度のチェックで十分としています。

最初のうちは、myisamchk -s を毎晩実行して、直前の 24 時間以内に更新されたすべてのテーブルをチェックするようにします。しばらくすると、MySQL の信頼性の高さを実感できるはずです。

通常、MySQL テーブルの保守はそれほど頻繁に行う必要はありません。動的サイズのレコード（VARCHAR カラム、BLOB カラム、または TEXT カラム）があるテーブルを変更したり、多くのレコードが削除されたテーブルがある場合には、月に一度程度、最適化を行ってテーブルの領域を解放することを推奨します。

これを行うには、目的のテーブルで OPTIMIZE TABLE を実行するか、mysqld サーバを停止して以下を実行します。

 
isamchk -r --silent --sort-index -O sort_buffer_size=16M */*.ISM
myisamchk -r --silent --sort-index  -O sort_buffer_size=16M */*.MYI

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.5.8 テーブル情報の取得

テーブルに関する情報またはその統計を取得するには、以下のコマンドを実行します。これらの情報については後で詳しく説明します。

myisamchk -d による出力例
 
MyISAM file:     company.MYI
Record format:   Fixed length
Data records:    1403698  Deleted blocks:         0
Recordlength:    226

table description:
Key Start Len Index   Type
1   2     8   unique  double
2   15    10  multip. text packed stripped
3   219   8   multip. double
4   63    10  multip. text packed stripped
5   167   2   multip. unsigned short
6   177   4   multip. unsigned long
7   155   4   multip. text
8   138   4   multip. unsigned long
9   177   4   multip. unsigned long
    193   1           text

myisamchk -d -v による出力例
 
MyISAM file:         company
Record format:       Fixed length
File-version:        1
Creation time:       1999-10-30 12:12:51
Recover time:        1999-10-31 19:13:01
Status:              checked
Data records:           1403698  Deleted blocks:              0
Datafile parts:         1403698  Deleted data:                0
Datafilepointer (bytes):      3  Keyfile pointer (bytes):     3
Max datafile length: 3791650815  Max keyfile length: 4294967294
Recordlength:               226

table description:
Key Start Len Index   Type                  Rec/key     Root Blocksize
1   2     8   unique  double                      1 15845376      1024
2   15    10  multip. text packed stripped        2 25062400      1024
3   219   8   multip. double                     73 40907776      1024
4   63    10  multip. text packed stripped        5 48097280      1024
5   167   2   multip. unsigned short           4840 55200768      1024
6   177   4   multip. unsigned long            1346 65145856      1024
7   155   4   multip. text                     4995 75090944      1024
8   138   4   multip. unsigned long              87 85036032      1024
9   177   4   multip. unsigned long             178 96481280      1024
    193   1           text

myisamchk -eis による出力例
 
Checking MyISAM file: company
Key:  1:  Keyblocks used:  97%  Packed:    0%  Max levels:  4
Key:  2:  Keyblocks used:  98%  Packed:   50%  Max levels:  4
Key:  3:  Keyblocks used:  97%  Packed:    0%  Max levels:  4
Key:  4:  Keyblocks used:  99%  Packed:   60%  Max levels:  3
Key:  5:  Keyblocks used:  99%  Packed:    0%  Max levels:  3
Key:  6:  Keyblocks used:  99%  Packed:    0%  Max levels:  3
Key:  7:  Keyblocks used:  99%  Packed:    0%  Max levels:  3
Key:  8:  Keyblocks used:  99%  Packed:    0%  Max levels:  3
Key:  9:  Keyblocks used:  98%  Packed:    0%  Max levels:  4
Total:    Keyblocks used:  98%  Packed:   17%

Records:          1403698    M.recordlength:     226
Packed:             0%
Recordspace used:     100%   Empty space:          0%
Blocks/Record:   1.00
Record blocks:    1403698    Delete blocks:        0
Recorddata:     317235748    Deleted data:         0
Lost space:             0    Linkdata:             0

User time 1626.51, System time 232.36
Maximum resident set size 0, Integral resident set size 0
Non physical pagefaults 0, Physical pagefaults 627, Swaps 0
Blocks in 0 out 0, Messages in 0 out 0, Signals 0
Voluntary context switches 639, Involuntary context switches 28966

myisamchk -eiv による出力例
 
Checking MyISAM file: company
Data records: 1403698   Deleted blocks:       0
- check file-size
- check delete-chain
block_size 1024:
index  1:
index  2:
index  3:
index  4:
index  5:
index  6:
index  7:
index  8:
index  9:
No recordlinks
- check index reference
- check data record references index: 1
Key:  1:  Keyblocks used:  97%  Packed:    0%  Max levels:  4
- check data record references index: 2
Key:  2:  Keyblocks used:  98%  Packed:   50%  Max levels:  4
- check data record references index: 3
Key:  3:  Keyblocks used:  97%  Packed:    0%  Max levels:  4
- check data record references index: 4
Key:  4:  Keyblocks used:  99%  Packed:   60%  Max levels:  3
- check data record references index: 5
Key:  5:  Keyblocks used:  99%  Packed:    0%  Max levels:  3
- check data record references index: 6
Key:  6:  Keyblocks used:  99%  Packed:    0%  Max levels:  3
- check data record references index: 7
Key:  7:  Keyblocks used:  99%  Packed:    0%  Max levels:  3
- check data record references index: 8
Key:  8:  Keyblocks used:  99%  Packed:    0%  Max levels:  3
- check data record references index: 9
Key:  9:  Keyblocks used:  98%  Packed:    0%  Max levels:  4
Total:    Keyblocks used:   9%  Packed:   17%

- check records and index references
[LOTS OF ROW NUMBERS DELETED]

Records:          1403698    M.recordlength:     226   Packed:             0%
Recordspace used:     100%   Empty space:          0%  Blocks/Record:   1.00
Record blocks:    1403698    Delete blocks:        0
Recorddata:     317235748    Deleted data:         0
Lost space:             0    Linkdata:             0

User time 1639.63, System time 251.61
Maximum resident set size 0, Integral resident set size 0
Non physical pagefaults 0, Physical pagefaults 10580, Swaps 0
Blocks in 4 out 0, Messages in 0 out 0, Signals 0
Voluntary context switches 10604, Involuntary context switches 122798

上記の例で使用されたテーブルのデータファイルおよびインデックスファイルのサイズは以下のとおりです。

 
-rw-rw-r--   1 monty    tcx     317235748 Jan 12 17:30 company.MYD
-rw-rw-r--   1 davida   tcx      96482304 Jan 12 18:35 company.MYI

以下、myisamchk が生成する情報のタイプについて説明します。"キーファイル" とはインデックスファイルのことです。"レコード" と "ロー" はシノニムです。

テーブルが myisampack で圧縮されている場合、myisamchk -d を実行すると、各テーブルカラムに関する追加情報が出力されます。これらの情報およびその意味については、 「4.8.4 myisampack（MySQL 圧縮読み取り専用テーブルジェネレータ）」 を参照してください。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.6 データベース管理言語リファレンス

4.6.1 OPTIMIZE TABLE 構文   
4.6.2 ANALYZE TABLE 構文   
4.6.3 CHECKSUM TABLE 構文   
4.6.4 FLUSH 構文   
4.6.5 RESET 構文   
4.6.6 PURGE MASTER LOGS 構文   
4.6.7 KILL 構文   
4.6.8 SHOW 構文   

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.6.1 OPTIMIZE TABLE 構文

 
OPTIMIZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_name[,tbl_name]...

OPTIMIZE TABLE は、テーブルの大部分を削除したり、可変長レコードを持つテーブル（VARCHAR カラム、BLOB カラム、または TEXT カラムを持つテーブル）に多くの変更を加えた場合に使用します。 削除されたレコードはリンクされたリストに保持され、元のレコード位置は、後続の INSERT 操作により再利用されます。OPTIMIZE TABLE を使用して未使用領域を解放し、データファイルを最適化することができます。

ほとんどの場合、OPTIMIZE TABLE を実行する必要はありません。可変長レコードに更新を多く行う場合でも、週または月に一度、特定のテーブルだけに実行するだけで十分です。

現在のところ、OPTIMIZE TABLE は MyISAM テーブルと BDB テーブルにのみ有効です。BDB テーブルでは、OPTIMIZE TABLE は現在 ANALYZE TABLE にマップされます。 「4.6.2 ANALYZE TABLE 構文」 節 参照 。

mysqld を --skip-new または --safe-mode で起動することにより、OPTIMIZE TABLE を他のテーブルタイプにでも使用できるようになります。しかしこの場合、OPTIMIZE TABLE は ALTER TABLE にマップされます。

OPTIMIZE TABLE は以下のように動作します。

注意: OPTIMIZE TABLE の実行中、テーブルはロックされます。

MySQL 4.1.1 より前のバージョンを使用している場合、OPTIMIZE コマンドはバイナリログに記録されません。MySQL 4.1.1 以降を使用している場合は、オプションの NO_WRITE_TO_BINLOG キーワード（またはそのエイリアスの LOCAL）を使用していない限り、バイナリログに記録されます。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.6.2 ANALYZE TABLE 構文

 
ANALYZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_name[,tbl_name...]

テーブルのキー分布を分析して保存します。分析中、テーブルは読み取りロックされます。このコマンドは、MyISAM テーブルと BDB テーブルに対して使用できます。

これは、テーブルに対して myisamchk -a を実行するのと同じです。

定数を条件としない結合を実行する場合、MySQL は保存されたキー分布を使用して、テーブルの結合順序を決定します。

このコマンドは、以下のカラムで構成されるテーブルを返します。

カラム 値
Table テーブル名
Op 常に analyze
Msg_type status、error、info、warning のいずれか
Msg_text メッセージ

保存されたキー分布をチェックするには、SHOW INDEX コマンドを使用します。 「4.6.8.1 データベース、テーブル、カラム、およびインデックスに関する情報の取得」 節 参照 。

前回の ANALYZE TABLE コマンドを実行した後でテーブルが変更されていない場合、テーブルに対して再度分析は実行されません。

MySQL 4.1.1 より前のバージョンを使用している場合、ANALYZE コマンドはバイナリログに記録されません。MySQL 4.1.1 以降を使用している場合は、オプションの NO_WRITE_TO_BINLOG キーワード（またはそのエイリアスの LOCAL）を使用していない限り、バイナリログに記録されます。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.6.3 CHECKSUM TABLE 構文

 
CHECKSUM TABLE tbl_name[,tbl_name ...] [ QUICK | EXTENDED ]

テーブルのチェックサムを報告します。QUICK を指定した場合、現時点のテーブルのチェックサムが報告されます。または、テーブルがチェックサムをサポートしていない場合は NULL が返されます。この処理時間は非常に短くて済みます。EXTENDED モードでは、テーブル全体がレコードごとに読み取られ、チェックサムが計算されます。大きなテーブルの場合は時間がかかります。デフォルトでは（QUICK でも EXTENDED でもない場合）、テーブルがチェックサムをサポートしていれば、現時点のチェックサムが返され、サポートしていなければ、テーブルがスキャンされます。

このコマンドは、MySQL 4.1.1 で導入されました。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.6.4 FLUSH 構文

 
FLUSH [LOCAL | NO_WRITE_TO_BINLOG] flush_option [,flush_option] ...

MySQL が使用している内部キャッシュを消去するには、FLUSH コマンドを使用します。FLUSH を実行するには、RELOAD 権限が必要です。

flush_option には、以下のいずれかを指定できます。

ホストテーブルをフラッシュすると、ホストが再び接続可能になる。 「A.2.5 Host '...' is blocked エラー」 節 参照 。 mysqld を -O max_connect_errors=999999999 で起動すると、このエラーを回避できる。 更新ログファイルまたはバイナリログファイルを拡張子なしで指定している場合、ログファイルの拡張子番号は前のファイルに 1 を加算した数になる。ファイル名に拡張子を使用している場合、MySQL は更新ログファイルを閉じて、再び開く。 「4.10.3 更新ログ」 節 参照 。 これは、SIGHUP シグナルを mysqld サーバに送信するのと同じである。
オプション 説明
HOSTS ホストキャッシュテーブルを空にする。ホストが IP アドレスを変更した場合や、エラーメッセージ Host ... is blocked が表示される場合には、ホストテーブルをフラッシュすることが必要である。MySQL サーバとの接続中に、特定のホストの 1 つのレコードで max_connect_errors を超えるエラーが発生した場合、MySQL は問題があると判断し、以後、ホストからの接続要求をブロックする。
DES_KEY_FILE サーバ起動時に --des-key-file オプションで指定されたファイルから、DES キーを再度読み込む。
LOGS すべてのログファイルを閉じて、再び開く。
PRIVILEGES mysql データベースの権限テーブルから権限を再読み込みする。
QUERY CACHE クエリキャッシュを最適化し、メモリの使用効率を高める。このコマンドは RESET QUERY CACHE とは異なり、キャッシュからクエリを削除しない。
TABLES 開いているテーブルをすべて閉じる。使用中のテーブルも強制的に閉じる。これにより、クエリキャッシュもフラッシュされる。
[TABLE | TABLES] tbl_name [,tbl_name...] 指定したテーブルだけをフラッシュする。
TABLES WITH READ LOCK 開いているテーブルをすべて閉じ、すべてのデータベースの全テーブルを読み取りロックする。このロックは UNLOCK TABLES を実行するまで解除されない。適宜スナップショットを取ることができる Veritas などのファイルシステムを使用している場合には、このコマンドがバックアップの作成に非常に便利である。
STATUS ほとんどのステータス変数を 0 にリセットする。これは、クエリをデバッグするときにのみ使用する。
USER_RESOURCES すべてのユーザリソースを 0 にリセットする。これにより、ブロックされていたユーザも再度ログイン可能になる。 「4.4.7 ユーザリソースの制限」 節 参照 。

MySQL 4.1.1 より前のバージョンを使用している場合、FLUSH コマンドはバイナリログに記録されません。MySQL 4.1.1 以降のバージョンを使用している場合には、オプションの NO_WRITE_TO_BINLOG キーワード（またはそのエイリアスの LOCAL）を使用していない限り、バイナリログに記録されます。また、このコマンドに LOGS、MASTER、SLAVE、TABLES WITH READ LOCK のいずれかの引数が含まれる場合も、バイナリログに記録されません。これらの引数はスレーブにレプリケートされると問題が発生する可能性があります。

上記コマンドのうちのいくつかには、mysqladmin ユーティリティで flush-hosts、flush-logs、flush-privileges、 flush-status、flush-tables の各コマンドを使用してアクセスすることもできます。

レプリケーションで使用する RESET コマンドも参照してください。 「4.6.5 RESET 構文」 節 参照 。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.6.5 RESET 構文

 
RESET reset_option [,reset_option] ...

RESET コマンドは設定をリセットします。FLUSH コマンドのより強力なバージョンとしても機能します。 「4.6.4 FLUSH 構文」 節 参照 。

RESET を実行するには、RELOAD 権限が必要です。

「4.11.7 マスタサーバを制御する SQL ステートメント」 節 参照 。
オプション 説明
MASTER インデックスファイル内のすべてのバイナリログを削除し、バイナリログインデックスファイルを空白にリセットする。これは、以前の FLUSH MASTER。
SLAVE スレーブから、マスタバイナリログ内の自分のレプリケーション位置を消去する。これは、以前の FLUSH SLAVE。 「4.11.8 スレーブサーバを制御する SQL ステートメント」 節 参照 。
QUERY CACHE クエリキャッシュからすべてのクエリ結果を削除する。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.6.6 PURGE MASTER LOGS 構文

 
PURGE {MASTER|BINARY} LOGS TO binlog_name
PURGE {MASTER|BINARY} LOGS BEFORE date

このコマンドは、指定したバイナリログまたは指定日より前のバイナリログをすべて削除する場合に使用します。 「4.11.7 マスタサーバを制御する SQL ステートメント」 節 参照 。

PURGE MASTER LOGS のシノニムとして PURGE BINARY LOGS が MySQL 4.1.1 から利用可能になっています。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.6.7 KILL 構文

 
KILL thread_id

mysqld の各接続はスレッドごとに行われます。SHOW PROCESSLIST コマンドで、どのスレッドが使用されているか知ることができます。また、KILL thread_id コマンドで、スレッドを強制終了できます。

PROCESS 権限があれば、すべてのスレッドを照会することができます。 SUPER 権限があれば、すべてのスレッドを強制終了できます。 上記の権限がない場合は、自分のスレッドだけ照会および強制終了できます。

mysqladmin processlist コマンドおよび mysqladmin kill コマンドでも、スレッドを確認および強制終了できます。

注意: 現在のところ、組み込み MySQL サーバライブラリでは KILL を使用できません。組み込みサーバは、ホストアプリケーションのスレッド内部で実行するだけで、独自の接続スレッドは作成しません。

KILL を実行すると、スレッド固有の kill flag がスレッドに設定されます。

キルフラグは一定間隔でチェックされるため、多くの場合、スレッドが終了するまでにしばらく時間がかかります。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.6.8 SHOW 構文

 
   SHOW DATABASES [LIKE wild]
か SHOW [OPEN] TABLES [FROM db_name] [LIKE wild]
か SHOW [FULL] COLUMNS FROM tbl_name [FROM db_name] [LIKE wild]
か SHOW INDEX FROM tbl_name [FROM db_name]
か SHOW TABLE STATUS [FROM db_name] [LIKE wild]
か SHOW STATUS [LIKE wild]
か SHOW VARIABLES [LIKE wild]
か SHOW [BDB] LOGS
か SHOW [FULL] PROCESSLIST
か SHOW GRANTS FOR user
か SHOW CREATE TABLE table_name
か SHOW MASTER STATUS
か SHOW MASTER LOGS
か SHOW SLAVE STATUS
か SHOW WARNINGS [LIMIT row_count]
か SHOW ERRORS [LIMIT row_count]
か SHOW TABLE TYPES

SHOW を実行すると、データベース情報、テーブル情報、カラム情報、またはサーバのステータス情報が提供されます。LIKE wild を使用した場合、wild 文字列内に SQL の `%' および `_' のワイルドカード文字を使用できます。

4.6.8.1 データベース、テーブル、カラム、およびインデックスに関する情報の取得   
4.6.8.2 SHOW TABLE STATUS   
4.6.8.3 SHOW STATUS   
4.6.8.4 SHOW VARIABLES   
4.6.8.5 SHOW [BDB] LOGS   
4.6.8.6 SHOW PROCESSLIST   
4.6.8.7 SHOW GRANTS   
4.6.8.8 SHOW CREATE TABLE   
4.6.8.9 SHOW WARNINGS | ERRORS   
4.6.8.10 SHOW TABLE TYPES   
4.6.8.11 SHOW PRIVILEGES   

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.6.8.1 データベース、テーブル、カラム、およびインデックスに関する情報の取得

tbl_name FROM db_name 構文の代わりに db_name.tbl_name を使用することもできます。以下の 2 つのステートメントは同じです。

 
mysql> SHOW INDEX FROM mytable FROM mydb;
mysql> SHOW INDEX FROM mydb.mytable;

SHOW DATABASES は、MySQL サーバホスト上のデータベースを一覧表示します。 mysqlshow コマンドラインツールを使用しても、この一覧を取得できます。 バージョン 4.0.2 では、ユーザにグローバル SHOW DATABASES 権限がない場合、そのユーザが何らかの権限を持つデータベースのみ表示されます。

SHOW TABLES は、指定したデータベースのテーブルを一覧表示します。mysqlshow db_name コマンドを使用しても、この一覧を取得できます。

注意: ユーザにテーブルに対する権限が何もない場合、SHOW TABLES および mysqlshow db_name の出力にそのテーブルは含まれません。

SHOW OPEN TABLES は、テーブルキャッシュで現在開いているテーブルを一覧表示します。 「5.4.7 MySQL でのテーブルのオープンとクローズの方法」 節 参照 。 Comment フィールドは、テーブルが何回キャッシャされ、使用されたかを示します。

SHOW COLUMNS は、指定したテーブルのカラムを一覧表示します。FULL オプションを指定した場合、ユーザが各カラムに持つ権限も表示されます。カラム情報で示されるカラムの型は、CREATE TABLE ステートメントで指定したものと異なっている場合があります。これは、カラムの型が MySQL によって自動的に変更されることがあるためです。 「6.5.3.1 カラムの暗黙的な変更」 節 参照 。 MySQL 4.1 から、FULL キーワードにより、カラム別コメントも表示されるようになりました。

DESCRIBE ステートメントでも SHOW COLUMNS と同様の情報が出力されます。 「6.6.2 DESCRIBE 構文（カラムに関する情報の取得）」 節 参照 。

SHOW FIELDS は SHOW COLUMNS のシノニムで、SHOW KEYS は SHOW INDEX のシノニムです。mysqlshow db_name tbl_name および mysqlshow -k db_name tbl_name でも、テーブルのカラムまたはインデックスを一覧表示できます。

SHOW INDEX は、ODBC での SQLStatistics 呼び出しとよく似た形式でインデックス情報を返します。以下のカラムが返されます。

MySQL ではこれは `A'（昇順）または NULL（ソートしない）になる。 これは、isamchk -a の実行によって更新される。 キー全体がインデックスになっている場合は NULL。
カラム 意味
Table テーブル名。
Non_unique インデックスに重複が許されない場合は 0、許される場合には 1。
Key_name インデックス名。
Seq_in_index インデックスのカラムシーケンス番号。1 から始まる。
Column_name カラム名。
Collation インデックスでのカラムのソート方法。
Cardinality インデックス内のユニークな値の数。
Sub_part カラムが部分的にインデックスになっている場合は、インデックスになっている文字数。
Null カラムに NULL を含めることができれば 'YES'。
Index_type 使用されるインデックス方式。
Comment さまざまなコメント。現在のところ、MySQL 4.0.2 より前のバージョンでは、インデックスが FULLTEXT か否かを表示。

注意: Cardinality は整数で保存された統計情報に基づいてカウントされるため、小さなテーブルについては正確であると限りません。

Null カラムおよび Index_type カラムは MySQL 4.0.2 で追加されました。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.6.8.2 SHOW TABLE STATUS

 
SHOW TABLE STATUS [FROM db_name] [LIKE wild]

SHOW TABLE STATUS（バージョン 3.23 で導入）は SHOW STATUS と似た働きをしますが、各テーブルに関する多くの情報を提供します。mysqlshow --status db_name コマンドを使用しても、この一覧を取得することができます。 以下のカラムが返されます。

固定レコード形式では、テーブルのレコードの最大数になる。 動的レコード形式では、テーブルに保存できるデータバイト数の合計（データポインタサイズの使用が前提）。
カラム 意味
Name テーブル名。
Type テーブル型。 「7. MySQL のテーブル型」 節 参照 。
Row_format レコードの保存形式（Fixed、Dynamic、または Compressed）。
Rows レコードの数。
Avg_row_length レコードの平均長。
Data_length データファイルの長さ。
Max_data_length データファイルの最大長。
Index_length インデックスファイルの大きさ。
Data_free 割り当てられているが未使用のバイト数。
Auto_increment 次の自動インクリメント値。
Create_time テーブル作成時刻。
Update_time 前回のデータファイル更新時刻。
Check_time 前回のテーブルチェック時刻。
Collation テーブルのキャラクタセットと照合順序（4.1.1 で導入）。
Checksum チェックサム値（ある場合）（4.1.1 で導入）。
Create_options CREATE TABLE で使用される拡張オプション。
Comment テーブル作成時のコメント（または MySQL がテーブル情報にアクセスできない理由）。

InnoDB テーブルでは、テーブルコメントにテーブルの空き領域が報告されます。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.6.8.3 SHOW STATUS

SHOW STATUS は、サーバのステータス情報を提供します（mysqladmin extended-status と同様）。出力は以下のようになります（形式と数値は場合によって異なります）。

 
+--------------------------+------------+
| Variable_name            | Value      |
+--------------------------+------------+
| Aborted_clients          | 0          |
| Aborted_connects         | 0          |
| Bytes_received           | 155372598  |
| Bytes_sent               | 1176560426 |
| Connections              | 30023      |
| Created_tmp_disk_tables  | 0          |
| Created_tmp_tables       | 8340       |
| Created_tmp_files        | 60         |
| Delayed_insert_threads   | 0          |
| Delayed_writes           | 0          |
| Delayed_errors           | 0          |
| Flush_commands           | 1          |
| Handler_delete           | 462604     |
| Handler_read_first       | 105881     |
| Handler_read_key         | 27820558   |
| Handler_read_next        | 390681754  |
| Handler_read_prev        | 6022500    |
| Handler_read_rnd         | 30546748   |
| Handler_read_rnd_next    | 246216530  |
| Handler_update           | 16945404   |
| Handler_write            | 60356676   |
| Key_blocks_used          | 14955      |
| Key_read_requests        | 96854827   |
| Key_reads                | 162040     |
| Key_write_requests       | 7589728    |
| Key_writes               | 3813196    |
| Max_used_connections     | 0          |
| Not_flushed_key_blocks   | 0          |
| Not_flushed_delayed_rows | 0          |
| Open_tables              | 1          |
| Open_files               | 2          |
| Open_streams             | 0          |
| Opened_tables            | 44600      |
| Questions                | 2026873    |
| Select_full_join         | 0          |
| Select_full_range_join   | 0          |
| Select_range             | 99646      |
| Select_range_check       | 0          |
| Select_scan              | 30802      |
| Slave_running            | OFF        |
| Slave_open_temp_tables   | 0          |
| Slow_launch_threads      | 0          |
| Slow_queries             | 0          |
| Sort_merge_passes        | 30         |
| Sort_range               | 500        |
| Sort_rows                | 30296250   |
| Sort_scan                | 4650       |
| Table_locks_immediate    | 1920382    |
| Table_locks_waited       | 0          |
| Threads_cached           | 0          |
| Threads_created          | 30022      |
| Threads_connected        | 1          |
| Threads_running          | 1          |
| Uptime                   | 80380      |
+--------------------------+------------+

上記のステータス変数にはそれぞれ以下のような意味があります。

この値が大きい場合、サーバが何回もフルインデックススキャンを実行していると考えられる。たとえば、SELECT col1 FROM foo を実行したときに col1 がインデックスになっているとそうなる。 結果のソートを必要とするクエリを多く実行すると、この値が大きくなる。 テーブルスキャンが多く実行されると、この値が大きくなる。この場合、一般的に、テーブルが適切にインデックス化されていないか、クエリがインデックスを有効に利用していないかを意味する。
変数 意味
Aborted_clients 接続を閉じる前にクライアントが終了してしまったために中断された接続数。 「A.2.10 通信エラー/Aborted connection」 節 参照 。
Aborted_connects MySQL サーバへの接続試行失敗回数。 「A.2.10 通信エラー/Aborted connection」 節 参照 。
Bytes_received すべてのクライアントから受信したバイト数。
Bytes_sent すべてのクライアントに送信されたバイト数。
Com_xxx 各 xxx コマンドの実行回数。
Connections MySQL サーバへの接続試行回数。
Created_tmp_disk_tables ステートメント実行中に、ディスク上に作成された暗黙的テンポラリテーブルの数。
Created_tmp_tables ステートメント実行中に、メモリ上に作成された暗黙的テンポラリテーブルの数。
Created_tmp_files mysqld が作成したテンポラリファイルの数。
Delayed_insert_threads INSERT DELAYED ハンドラスレッドの数。
Delayed_writes INSERT DELAYED で書き込まれたレコードの数。
Delayed_errors エラー発生（重複キーの可能性が高い）により、INSERT DELAYED で書き込まれたレコードの数。
Flush_commands FLUSH コマンドの実行回数。
Handler_commit 内部 COMMIT コマンド数。
Handler_delete テーブルからレコードが削除された回数。
Handler_read_first 最初のエントリがインデックスから読み取られた回数。
Handler_read_key キーに基づくレコード読み取り要求の回数。この値が大きい場合、クエリおよびテーブルが適切にインデックス化されていると考えられる。
Handler_read_next キー順序での次のレコードの読み取り要求の回数。範囲指定をしてインデックスカラムに対してクエリを実行すると、これがインクリメントされる。インデックススキャンを実行してもインクリメントされる。
Handler_read_prev キー順序での前のレコードの読み取り要求の回数。これは主に、ORDER BY ... DESC を最適化するのに使用される。
Handler_read_rnd 固定位置に基づくレコード読み取り要求の回数。
Handler_read_rnd_next データファイルでの次のレコードの読み取り要求の回数。
Handler_rollback 内部 ROLLBACK コマンド数。
Handler_update テーブル内のレコードの更新要求回数。
Handler_write テーブルへのレコードの挿入要求回数。
Key_blocks_used キーキャッシュの使用ブロック数。
Key_read_requests キャッシュからのキーブロック読み取り要求回数。
Key_reads ディスクからのキーブロックの物理的読み取り回数。
Key_write_requests キャッシュへのキーブロックの書き込み要求回数。
Key_writes ディスクへのキーブロックの物理的書き込み回数。
Max_used_connections 同時使用可能な最大接続数。
Not_flushed_key_blocks 変更されたが、ディスクへのフラッシュはまだされていないキーキャッシュのキーブロック。
Not_flushed_delayed_rows INSERT DELAY キューで書き込みを待っているレコードの数。
Open_tables 開いているテーブルの数。
Open_files 開いているファイルの数。
Open_streams 開いているストリームの数（主にログ用に使用）。
Opened_tables 開かれたテーブルの数。
Rpl_status フェールセーフなレプリケーションのステータス（まだ使用されていない）。
Select_full_join キーを使用しない結合の数（この値が 0 でない場合、テーブルのインデックスをチェックする必要がある）。
Select_full_range_join 参照テーブルで範囲指定の検索を使用した結合の数。
Select_range 最初のテーブルの範囲指定された部分のみを使用した結合の数（通常、この値が大きくても問題にはならない）。
Select_scan 最初のテーブルでフルスキャンを行った結合の数。
Select_range_check 各レコードの後でキー使用をチェックする、キーを使用しない結合の数（この値が 0 でない場合、テーブルのインデックスをチェックする必要がある）。
Questions サーバに送信されたクエリの数。
Slave_open_temp_tables スレーブスレッドによって現在開かれているテンポラリテーブルの数。
Slave_running マスタに接続されているスレーブの場合は ON。
Slow_launch_threads 生成に slow_launch_time より時間がかかったスレッドの数。
Slow_queries long_query_time 秒より時間がかかったクエリの数。 「4.10.5 スロークエリログ」 節 参照 。
Sort_merge_passes ソートアルゴリズムで必要だったマージパスの回数。この値が大きければ、sort_buffer の値を大きくすることを考慮すべきである。
Sort_range 範囲指定で行われたソートの回数。
Sort_rows ソートされたレコードの数。
Sort_scan テーブルのスキャンによって実行されたソートの回数。
ssl_xxx SSL によって使用される変数（まだ導入されていない）。
Table_locks_immediate テーブルロックがすぐに実行された回数。3.23.33 で導入。
Table_locks_waited テーブルロックがすぐには実行されず、待機が必要だった回数。この値が大きい場合、パフォーマンス上の問題がある。まずクエリを最適化し、次にテーブルを分割するかレプリケーションを使用すべきである。3.23.33 で導入。
Threads_cached スレッドキャッシュ内のスレッド数。
Threads_connected 現在開いている接続の数。
Threads_created 接続を処理するために作成されたスレッドの数。
Threads_running スリープ状態になっていないスレッドの数。
Uptime サーバの稼動秒数。

補足コメント

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.6.8.4 SHOW VARIABLES

 
SHOW [GLOBAL | SESSION] VARIABLES [LIKE wild]

SHOW VARIABLES は、MySQL システム変数の値を表示します。 GLOBAL オプションおよび SESSION オプションは MySQL 4.0.3 で追加されました。 GLOBAL では、MySQL の新規接続に使用される変数を得ることができます。SESSION では、現在の接続に有効な値を得ることができます。オプションを特に指定しなければ、SESSION が使用されます。

デフォルト値が適当ではない場合には、mysqld 起動時にコマンドラインオプションを使用して、これらの変数のほとんどを変更できます。 「4.1.1 mysqld コマンドラインオプション」 節 参照 。 SET ステートメントからでも、ほとんどの変数を変更できます。 「5.5.6 SET 構文」 節 参照 。

SHOW VARIABLES の出力は以下のようになります（形式と数値は場合によって異なります）。 mysqladmin variables コマンドを使用しても同じ情報を取得できます。

 
+---------------------------------+------------------------------+
| Variable_name                   | Value                        |
+---------------------------------+------------------------------|
| back_log                        | 50                           |
| basedir                         | /usr/local/mysql             |
| bdb_cache_size                  | 8388572                      |
| bdb_log_buffer_size             | 32768                        |
| bdb_home                        | /usr/local/mysql             |
| bdb_max_lock                    | 10000                        |
| bdb_logdir                      |                              |
| bdb_shared_data                 | OFF                          |
| bdb_tmpdir                      | /tmp/                        |
| bdb_version                     | Sleepycat Software: ...      |
| binlog_cache_size               | 32768                        |
| bulk_insert_buffer_size         | 8388608                      |
| character_set                   | latin1                       |
| character_sets                  | latin1 big5 czech euc_kr     |
| concurrent_insert               | ON                           |
| connect_timeout                 | 5                            |
| convert_character_set           |                              |
| datadir                         | /usr/local/mysql/data/       |
| delay_key_write                 | ON                           |
| delayed_insert_limit            | 100                          |
| delayed_insert_timeout          | 300                          |
| delayed_queue_size              | 1000                         |
| flush                           | OFF                          |
| flush_time                      | 0                            |
| ft_boolean_syntax               | + -><()~*:""&|               |
| ft_min_word_len                 | 4                            |
| ft_max_word_len                 | 84                           |
| ft_query_expansion_limit        | 20                           |
| ft_stopword_file                | (built-in)                   |
| have_bdb                        | YES                          |
| have_innodb                     | YES                          |
| have_isam                       | YES                          |
| have_raid                       | NO                           |
| have_symlink                    | DISABLED                     |
| have_openssl                    | YES                          |
| have_query_cache                | YES                          |
| init_file                       |                              |
| innodb_additional_mem_pool_size | 1048576                      |
| innodb_buffer_pool_size         | 8388608                      |
| innodb_data_file_path           | ibdata1:10M:autoextend       |
| innodb_data_home_dir            |                              |
| innodb_file_io_threads          | 4                            |
| innodb_force_recovery           | 0                            |
| innodb_thread_concurrency       | 8                            |
| innodb_flush_log_at_trx_commit  | 1                            |
| innodb_fast_shutdown            | ON                           |
| innodb_flush_method             |                              |
| innodb_lock_wait_timeout        | 50                           |
| innodb_log_arch_dir             |                              |
| innodb_log_archive              | OFF                          |
| innodb_log_buffer_size          | 1048576                      |
| innodb_log_file_size            | 5242880                      |
| innodb_log_files_in_group       | 2                            |
| innodb_log_group_home_dir       | ./                           |
| innodb_mirrored_log_groups      | 1                            |
| interactive_timeout             | 28800                        |
| join_buffer_size                | 131072                       |
| key_buffer_size                 | 16773120                     |
| language                        | /usr/local/mysql/share/...   |
| large_files_support             | ON                           |
| local_infile                    | ON                           |
| locked_in_memory                | OFF                          |
| log                             | OFF                          |
| log_update                      | OFF                          |
| log_bin                         | OFF                          |
| log_slave_updates               | OFF                          |
| log_slow_queries                | OFF                          |
| log_warnings                    | OFF                          |
| long_query_time                 | 10                           |
| low_priority_updates            | OFF                          |
| lower_case_table_names          | OFF                          |
| max_allowed_packet              | 1047552                      |
| max_binlog_cache_size           | 4294967295                   |
| max_binlog_size                 | 1073741824                   |
| max_connections                 | 100                          |
| max_connect_errors              | 10                           |
| max_delayed_threads             | 20                           |
| max_heap_table_size             | 16777216                     |
| max_join_size                   | 4294967295                   |
| max_relay_log_size              | 0                            |
| max_sort_length                 | 1024                         |
| max_user_connections            | 0                            |
| max_tmp_tables                  | 32                           |
| max_write_lock_count            | 4294967295                   |
| myisam_max_extra_sort_file_size | 268435456                    |
| myisam_repair_threads           | 1                            |
| myisam_max_sort_file_size       | 2147483647                   |
| myisam_recover_options          | force                        |
| myisam_sort_buffer_size         | 8388608                      |
| net_buffer_length               | 16384                        |
| net_read_timeout                | 30                           |
| net_retry_count                 | 10                           |
| net_write_timeout               | 60                           |
| open_files_limit                | 1024                         |
| pid_file                        | /usr/local/mysql/name.pid    |
| port                            | 3306                         |
| protocol_version                | 10                           |
| query_cache_limit               | 1048576                      |
| query_cache_size                | 0                            |
| query_cache_type                | ON                           |
| read_buffer_size                | 131072                       |
| read_rnd_buffer_size            | 262144                       |
| rpl_recovery_rank               | 0                            |
| safe_show_database              | OFF                          |
| server_id                       | 0                            |
| slave_net_timeout               | 3600                         |
| skip_external_locking           | ON                           |
| skip_networking                 | OFF                          |
| skip_show_database              | OFF                          |
| slow_launch_time                | 2                            |
| socket                          | /tmp/mysql.sock              |
| sort_buffer_size                | 2097116                      |
| sql_mode                        |                              |
| table_cache                     | 64                           |
| table_type                      | MYISAM                       |
| thread_cache_size               | 3                            |
| thread_stack                    | 131072                       |
| tx_isolation                    | READ-COMMITTED               |
| timezone                        | EEST                         |
| tmp_table_size                  | 33554432                     |
| tmpdir                          | /tmp/:/mnt/hd2/tmp/          |
| version                         | 4.0.4-beta                   |
| wait_timeout                    | 28800                        |
+---------------------------------+------------------------------+

以下、各オプションについて説明します。

バッファサイズ、長さ、およびスタックサイズの値はバイト単位です。 `K' または `M' のサフィックスを値に付けると、それぞれキロバイト、メガバイトを示します。たとえば、16M は 16 メガバイトです。サフィックスの大文字と小文字は区別されません。16M と 16m は同じです。

これら変数のチューニング方法については、MySQL のチューニングに関するセクションを参照してください。 「5.5.2 サーバパラメータのチューニング」 節 参照 。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.6.8.5 SHOW [BDB] LOGS

SHOW LOGS は、既存のログファイルに関するステータス情報を表示します。現在は、Berkeley DB ログファイルの情報を表示するだけなので、そのエイリアスは（MySQL 4.1.1 で導入） SHOW BDB LOGS です。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.6.8.6 SHOW PROCESSLIST

SHOW [FULL] PROCESSLIST は、実行中のスレッドを表示します。 mysqladmin processlist コマンドでもこの情報を取得できます。SUPER 権限があれば、すべてのスレッドを表示できます。この権限がない場合は、自分のスレッドのみ表示できます。 「4.6.7 KILL 構文」 節 参照 。 FULL オプションを使用していない場合、各クエリの最初の 100 文字だけが表示されます。

4.0.12 以降、MySQL は TCP/IP 接続のホスト名を hostname:client_port 形式で報告するので、どのクライアントが何を行っているかわかりやすくなっています。

このコマンドは、'too many connections' エラーメッセージが表示され、原因を知りたいときに便利です。MySQL は、SUPER 権限を持つクライアントのために 1 つの特別接続枠を予約しており、いつでもシステムにログインしてチェックできるようになっています（ユーザ全員にこの権限を与えていないようにしてください）。

mysqladmin processlist で確認できる一般的な状態は以下のとおりです。

ほとんどの状態はすぐに終わります。何秒も同じ状態が続く場合は、問題のある可能性があるので、調査が必要です。

他にも説明していない状態がありますが、そのほとんどは mysqld のバグ発見に役立つものです。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.6.8.7 SHOW GRANTS

SHOW GRANTS FOR user は、ユーザの権限を複製するために発行する必要がある grant コマンドを列挙します。

 
mysql> SHOW GRANTS FOR root@localhost;
+---------------------------------------------------------------------+
| Grants for root@localhost                                           |
+---------------------------------------------------------------------+
| GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' WITH GRANT OPTION |
+---------------------------------------------------------------------+

現在のセッションの権限を列挙するには、CURRENT_USER() 関数（バージョン 4.0.6 で導入）を使用して、そのセッションで認証されているユーザを確認できます。 「6.3.6.2 その他の各種関数」 節 参照 。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.6.8.8 SHOW CREATE TABLE

指定したテーブルを作成する CREATE TABLE ステートメントを表示します。

 
mysql> SHOW CREATE TABLE t\G
*************************** 1. row ***************************
       Table: t
Create Table: CREATE TABLE t (
  id INT(11) default NULL auto_increment,
  s char(60) default NULL,
  PRIMARY KEY (id)
) TYPE=MyISAM

SHOW CREATE TABLE で表示されるテーブル名とカラム名は、SQL_QUOTE_SHOW_CREATE オプションの値に従って引用符で囲まれます。 「5.5.6 SET 構文」 。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.6.8.9 SHOW WARNINGS | ERRORS

 
SHOW WARNINGS [LIMIT row_count]
SHOW ERRORS [LIMIT row_count]

このコマンドは、MySQL 4.1.0 で導入されました。

これは、前回のコマンドでのエラー、警告、およびコメントを表示します。エラーおよび警告は、テーブルを使用する新規コマンドごとにリセットされます。

MySQL サーバは、前回のコマンドで発生した警告とエラーの合計数を返します。これは、mysql_warning_count() を呼び出すことによって取得できます。

max_error_count までのメッセージが保存されます（グローバルおよびスレッド固有変数）。

@error_count でエラー数を、@warning_count で警告数を取得できます。

SHOW WARNINGS では前回のコマンドで発生したエラー、警告、およびコメントがすべて表示され、SHOW ERRORS ではエラーだけが表示されます。

 
mysql> DROP TABLE IF EXISTS no_such_table;
mysql> SHOW WARNINGS;

+-------+------+-------------------------------+
| Level | Code | Message                       |
+-------+------+-------------------------------+
| Note  | 1051 | Unknown table 'no_such_table' |
+-------+------+-------------------------------+

注意: MySQL 4.1.0 では警告のフレームワークが追加されただけなので、MySQL コマンドの多くは警告を生成しません。4.1.1 では、LOAD DATA INFILE、および INSERT、UPDATE、ALTER などの DML ステートメントのあらゆる種類の警告をサポートします。

以下、挿入ステートメントの変換警告を生成する簡単な例を示します。

 
mysql> create table t1(a tinyint NOT NULL, b char(4));
Query OK, 0 rows affected (0.00 sec)

mysql> insert into t1 values(10,'mysql'),(NULL,'test'),(300,'open source');
Query OK, 3 rows affected, 4 warnings (0.15 sec)
Records: 3  Duplicates: 0  Warnings: 4

mysql> show warnings;
+---------+------+---------------------------------------------------------------+
| Level   | Code | Message                                                       |
+---------+------+---------------------------------------------------------------+
| Warning | 1263 | Data truncated for column 'b' at row 1                        |
| Warning | 1261 | Data truncated, NULL supplied to NOT NULL column 'a' at row 2 |
| Warning | 1262 | Data truncated, out of range for column 'a' at row 3          |
| Warning | 1263 | Data truncated for column 'b' at row 3                        |
+---------+------+---------------------------------------------------------------+
4 rows in set (0.00 sec)

警告の最大数は、サーバ変数 'max_error_count'、SET max_error_count=[count] を使用して指定できます。デフォルトは 64 です。この変数を '0' にリセットすればこの設定を無効できます。max_error_count が 0 の場合でも、警告が何回発生したか表示されますが、メッセージは保存されません。

たとえば、上記の例での以下の ALTER テーブルステートメントの場合、max_error_count=1 に設定すると、警告が 3 回発生しても、返される警告メッセージは 1 つだけになります。

 
mysql> show variables like 'max_error_count';
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| max_error_count | 64    |
+-----------------+-------+
1 row in set (0.00 sec)

mysql> set max_error_count=1;
Query OK, 0 rows affected (0.00 sec)

mysql> alter table t1 modify b char;
Query OK, 3 rows affected, 3 warnings (0.00 sec)
Records: 3  Duplicates: 0  Warnings: 3

mysql> show warnings;
+---------+------+----------------------------------------+
| Level   | Code | Message                                |
+---------+------+----------------------------------------+
| Warning | 1263 | Data truncated for column 'b' at row 1 |
+---------+------+----------------------------------------+
1 row in set (0.00 sec)

mysql>

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.6.8.10 SHOW TABLE TYPES

 
SHOW TABLE TYPES

このコマンドは、MySQL 4.1.0 で導入されました。

SHOW TABLE TYPES は、テーブル型に関するステータス情報を表示します。このコマンドは、テーブル型がサポートされているかどうか、およびデフォルトのテーブル型を確認するのに使用されます。

 
mysql> SHOW TABLE TYPES;

+--------+---------+-----------------------------------------------------------+
| Type   | Support | Comment                                                   |
+--------+---------+-----------------------------------------------------------+
| MyISAM | DEFAULT | Default type from 3.23 with great performance             |
| HEAP   | YES     | Hash based, stored in memory, useful for temporary tables |
| MERGE  | YES     | Collection of identical MyISAM tables                     |
| ISAM   | YES     | Obsolete table type; Is replaced by MyISAM                |
| InnoDB | YES     | Supports transactions, row-level locking and foreign keys |
| BDB    | NO      | Supports transactions and page-level locking              |
+--------+---------+-----------------------------------------------------------+
6 rows in set (0.00 sec)

'Support' フィールドの DEFAULT は、そのテーブル型がサポートされていることと、テーブル型がデフォルトであることを示します。サーバを --default-table-type=InnoDB で起動した場合、InnoDB の 'Support' フィールド値が DEFAULT になります。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.6.8.11 SHOW PRIVILEGES

 
SHOW PRIVILEGES

このコマンドは、MySQL 4.1.0 で導入されました。

SHOW PRIVILEGES は、下の MySQL サーバがサポートするシステム権限を一覧表示します。

 
mysql> show privileges;
+------------+--------------------------+-------------------------------------------------------+
| Privilege  | Context                  | Comment                                               |
+------------+--------------------------+-------------------------------------------------------+
| Select     | Tables                   | To retrieve rows from table                           |
| Insert     | Tables                   | To insert data into tables                            |
| Update     | Tables                   | To update existing rows                               |
| Delete     | Tables                   | To delete existing rows                               |
| Index      | Tables                   | To create or drop indexes                             |
| Alter      | Tables                   | To alter the table                                    |
| Create     | Databases,Tables,Indexes | To create new databases and tables                    |
| Drop       | Databases,Tables         | To drop databases and tables                          |
| Grant      | Databases,Tables         | To give to other users those privileges you possess   |
| References | Databases,Tables         | To have references on tables                          |
| Reload     | Server Admin             | To reload or refresh tables, logs and privileges      |
| Shutdown   | Server Admin             | To shutdown the server                                |
| Process    | Server Admin             | To view the plain text of currently executing queries |
| File       | File access on server    | To read and write files on the server                 |
+------------+--------------------------+-------------------------------------------------------+
14 rows in set (0.00 sec)

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.7 MySQL のローカライズと国際的な使用

4.7.1 データおよびソート用キャラクタセット   
4.7.2 英語以外のエラーメッセージ   
4.7.3 新しいキャラクタセットの追加   
4.7.4 キャラクタ定義配列   
4.7.5 文字列照合サポート   
4.7.6 マルチバイト文字サポート   
4.7.7 キャラクタセットに関する問題   

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.7.1 データおよびソート用キャラクタセット

デフォルトでは、MySQL はスウェーデン語およびフィンランド語に従ってソートされる ISO-8859-1（Latin1）キャラクタセットを使用します。これは、米国と西ヨーロッパに適したキャラクタセットです。

標準 MySQL バイナリは、--with-extra-charsets=complex でコンパイルされます。これにより、すべての標準プログラムにコードが追加され、バイナリ内で latin1 とすべてのマルチバイトキャラクタセットを処理できるようになります。他のキャラクタセットが必要な場合は、キャラクタセット定義ファイルからロードします。

キャラクタセットにより、名前に使用できる文字と、SELECT ステートメントの ORDER BY 節および GROUP BY 節での文字列のソート方法が決定します。

サーバ起動時に --default-character-set オプションでキャラクタセットを変更できます。利用可能なキャラクタセットは、--with-charset=charset オプションと --with-extra-charsets= list-of-charset | complex | all | none オプションが configure になっているかどうか、および `SHAREDIR/charsets/Index' に含まれているキャラクタセット設定ファイルに依存します。 「2.3.3 一般的な configure オプション」 節 参照 。

MySQL の実行中にキャラクタセットを変更した場合（ソート順序が変わる可能性もあります）、すべてのテーブルで myisamchk -r -q --set-character-set=charset を実行する必要があります。このことを行わない場合、インデックスが正しい順序でなくなる可能性があります。

クライアントが MySQL サーバに接続すると、サーバはデフォルトのキャラクタセットをクライアントに送ります。クライアントは、この接続用としてそのキャラクタセットに切り替えます。

SQL クエリの文字列をエスケープする場合は、mysql_real_escape_string() を使用してください。最初のパラメータとして MYSQL 接続ハンドルを使用すること以外、mysql_real_escape_string() は旧 mysql_escape_string() 関数と同じです。

サーバのインストールパス以外のパスでクライアントがコンパイルされており、MySQL をコンフィギャしたユーザがすべてのキャラクタセットを MySQL バイナリに組み込んでいない場合、サーバがクライアントとは異なるキャラクタセットで実行しているときに必要となる追加キャラクタセットの場所を、クライアントに指定する必要があります。

これは、MySQL オプション設定ファイルで指定することができます。

 
[client]
character-sets-dir=/usr/local/mysql/share/mysql/charsets

ここで、パスは、動的 MySQL キャラクタセットが保存されているディレクトリを指します。

以下のように、クライアントに特定のキャラクタセットの使用を強制することも可能です。

 
[client]
default-character-set=character-set-name

しかし、通常は必要ありません。

4.7.1.1 ドイツ語キャラクタセット   

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.7.1.1 ドイツ語キャラクタセット

ドイツ語のソート順序が必要な場合、mysqld を --default-character-set=latin1_de で起動します。これには、以下のような特徴があります。

文字列のソートおよび比較時、比較の実行前に以下の文字列のマッピングが実行される。

 
@"a  ->  ae
@"o  ->  oe
@"u  ->  ue
ß  ->  ss

アクセント文字はすべて、対応するアクセントなしの大文字に変換されます。また、すべての文字が大文字に変換されます。

文字列を LIKE で比較する際には、1 文字から 2 文字へのマッピングは実行されません。すべての文字が大文字に変換されます。@"U、@"u、@"O、@"o、@"A、および @"a 以外、すべての文字からアクセントが削除されます。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.7.2 英語以外のエラーメッセージ

mysqld では、以下の言語でエラーメッセージを出力できます。 チョコ語、デンマーク語、オランダ語、英語（デフォルト）、エストニア語、フランス語、ドイツ語、ギリシャ語、ハンガリー語、イタリア語、日本語、韓国語、ノルウェー語、新ノルウェー語、ポーランド語、ポルトガル語、ルーマニア語、ロシア語、スロバキア語、スペイン語、およびスウェーデン語。

特定の言語で mysqld を起動するには、--language=lang または -L lang オプションを使用します。次に例を示します。

 
shell> mysqld --language=swedish

または

 
shell> mysqld --language=/usr/local/share/swedish

注意: 言語名はすべて小文字で指定します。

言語ファイルは（デフォルトで）`mysql_base_dir/share/LANGUAGE/' にあります。

エラーメッセージファイルを更新するには、`errmsg.txt' ファイルを編集し、以下のコマンドを実行して `errmsg.sys' ファイルを生成します。

 
shell> comp_err errmsg.txt errmsg.sys

MySQL を新しいバージョンにアップグレードした場合、この変更を、新規 `errmsg.txt' ファイルでも同じように行ってください。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.7.3 新しいキャラクタセットの追加

他のキャラクタセットを MySQL に追加するには、以下の手順を実行します。

キャラクタセットがシンプルなものかコンプレックスなものかを判断します。キャラクタセットが、ソートのために特殊文字照合ルーチンを必要とせず、マルチバイト文字のサポートも必要なければ、それはシンプルです。どちらかを必要とする場合、それはコンプレックスです。

たとえば、latin1 と danish はシンプルなキャラクタセットで、big5 や czech はコンプレックスなキャラクタセットです。

以下のセクションでは、キャラクタセットを MYSET という名前にすることが前提です。

シンプルなキャラクタセットの場合、以下を実行します。

  1. MYSET を `sql/share/charsets/Index' ファイルの最後に追加し、これに一意の番号を割り当てる。

  2. `sql/share/charsets/MYSET.conf' ファイルを作成する（`sql/share/charsets/latin1.conf' をベースとして使用できる）。

    ファイルの構文は、以下のとおり非常にシンプルである。

    「4.7.4 キャラクタ定義配列」 節 参照 。

  3. キャラクタセット名を、configure.in の CHARSETS_AVAILABLE リストおよび COMPILED_CHARSETS リストに追加する。

  4. 再コンフィギャして再コンパイルし、テストする。

コンプレックスなキャラクタセットの場合、以下を実行します。

  1. MySQL ソースディストリビューションに `strings/ctype-MYSET.c' ファイルを作成する。

  2. MYSET を `sql/share/charsets/Index' ファイルの最後に追加する。これに一意の番号を割り当てる。

  3. `strings/ctype-big5.c' など、既存の `ctype-*.c' ファイルの 1 つを見て、何の定義が必要か調べる。注意: ファイル内の配列名は、ctype_MYSET、to_lower_MYSET などであることが必要。これは、シンプルなキャラクタセットの配列に対応する。 「4.7.4 キャラクタ定義配列」 節 参照 。

  4. ファイルの先頭付近に、以下のようなコメントを置く。

     
    /*
 * This comment is parsed by configure to create ctype.c,
 * so don't change it unless you know what you are doing.
 *
 * .configure. number_MYSET=MYNUMBER
 * .configure. strxfrm_multiply_MYSET=N
 * .configure. mbmaxlen_MYSET=N
 */

    configure プログラムはこのコメントを使用して、自動的にキャラクタセットを MySQL ライブラリに組み込む。

    strxfrm_multiply 行および mbmaxlen 行については、後続セクションで説明する。これらはそれぞれ、文字列照合関数またはマルチバイト文字セット関数が必要な場合に組み込む。

  5. 次に、以下の関数を作成する。

    「4.7.5 文字列照合サポート」 節 参照 。

  6. キャラクタセット名を、configure.in の CHARSETS_AVAILABLE リストおよび COMPILED_CHARSETS リストに追加する。

  7. 再コンフィギャして再コンパイルし、テストする。

`sql/share/charsets/README' ファイルに、より詳細な説明が含まれています。

MySQL ディストリビューションへのキャラクタセットの組み込みを希望する場合には、MySQL internals メーリングリストにパッチをメールしてください。 「1.7.1.1 MySQL メーリングリスト」 節 参照 。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.7.4 キャラクタ定義配列

to_lower[] と to_upper[] は、キャラクタセットの各メンバに対応する、大文字と小文字が格納されるシンプルな配列です。次に例を示します。

 
to_lower['A'] は 'a' を含む
to_upper['a'] は 'A' を含む

sort_order[] は、文字をどのような順番で比較しソートするかを示すマップです。多くの場合（すべてのキャラクタセットについてではありませんが）、これは to_upper[] と同じです（ソートで大文字と小文字が区別されません）。MySQL は、sort_order[character] の値に基づいて文字をソートします。さらに複雑なソートルールに関しては、後述の文字列照合の説明を参照してください。 「4.7.5 文字列照合サポート」 節 参照 。

ctype[] はビット値の配列で、1 文字が 1 要素です。注意: to_lower[]、to_upper[]、および sort_order[] は文字値でインデックス化されますが、ctype[] は文字値 + 1 でインデックス化されます。これは、EOF を処理することが必要だったときの古いレガシです。

`m_ctype.h' に、以下のビットマスク定義があります。

 
#define _U      01      /* Uppercase */
#define _L      02      /* Lowercase */
#define _N      04      /* Numeral (digit) */
#define _S      010     /* Spacing character */
#define _P      020     /* Punctuation */
#define _C      040     /* Control character */
#define _B      0100    /* Blank */
#define _X      0200    /* heXadecimal digit */

各文字の ctype[] エントリは、文字を指定するビットマスク値の組み合わせになっている必要があります。たとえば、'A' は大文字（_U）であると同時に 16 進数（_X）でもあるので、ctype['A'+1] には以下の値が含まれます。

 
_U + _X = 01 + 0200 = 0201

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.7.5 文字列照合サポート

使用する言語のソートルールが、シンプルな sort_order[] テーブルで処理するには複雑すぎる場合、文字列照合を行う必要があります。

現在のところ、これに関する最良のドキュメントは、すでに実装されているキャラクタセットです。たとえば、big5、czech、gbk、sjis、tis160 などのキャラクタセットを見てみてください。

ファイルの先頭の特殊コメントで、strxfrm_multiply_MYSET=N 値を指定する必要があります。N には、my_strxfrm_MYSET で文字列が大きくなれる最大比率（正の整数）を設定してください。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.7.6 マルチバイト文字サポート

マルチバイト文字を含む新しいキャラクタセットのサポートを追加する場合、マルチバイト文字関数を使用する必要があります。

現在のところ、これに関する最良のドキュメントは、すでに実装されているキャラクタセットです。たとえば、euc_kr、gb2312、gbk、sjis、ujis などのキャラクタセットを参照してください。これらは、`strings' ディレクトリの `ctype-'charset'.c' ファイルに実装されています。

ソースファイルの先頭の特殊コメントで mbmaxlen_MYSET=N 値を指定する必要があります。N には、キャラクタセット内の最大文字のバイト数を設定してください。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.7.7 キャラクタセットに関する問題

使用しているバイナリにコンパイルされていないキャラクタセットを使用すると、いくつかの問題が発生する可能性があります。

MyISAM テーブルでは、テーブルのキャラクタセットの名前と番号を myisamchk -dvv table_name で確認できます。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.8 MySQL サーバサイドのスクリプトとユーティリティ

4.8.1 サーバサイドのスクリプトとユーティリティの概要   
4.8.2 mysqld_safe（mysqld のラッパ）   
4.8.3 mysqld_multi（複数の MySQL サーバを管理するプログラム）   
4.8.4 myisampack（MySQL 圧縮読み取り専用テーブルジェネレータ）   
4.8.5 mysqld-max（拡張 mysqld サーバ）   

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.8.1 サーバサイドのスクリプトとユーティリティの概要

すべての MySQL プログラムが多くのさまざまなオプションを使用します。しかし、すべての MySQL プログラムに --help オプションが用意されており、このオプションを使用することにより、そのプログラムのすべてのオプションの説明を表示することができます。たとえば、mysql --help を試してみてください。

すべての標準プログラムのデフォルトオプションは、オプション設定ファイルで上書きできます。 「4.1.2 `my.cnf' オプション設定ファイル」 。

以下の一覧は、サーバサイドの MySQL プログラムを簡単に説明したものです。

myisamchk
MySQL テーブルの記述、チェック、最適化、および修復を行うユーティリティ。myisamchk には多くの機能があるため、別の章で説明する。 「4. データベース管理」 節 参照 。

make_binary_distribution
コンパイルされた MySQL のバイナリリリースを作成する。作成したリリースは、他の MySQL ユーザが利用できるように、FTP 経由で support.mysql.com の `/pub/mysql/Incoming' に送信することができる。

mysqlbug
MySQL バグレポートスクリプト。このスクリプトは、MySQL リストにバグレポートを提出する際、必ず使用する。

mysqld
SQL デーモン。常に稼動していることが必要である。

mysql_install_db
MySQL 権限テーブルをデフォルト権限で作成する。これは通常、最初に MySQL をシステムにインストールするとき、1 回だけ実行する。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.8.2 mysqld_safe（mysqld のラッパ）

mysqld_safe は、mysqld デーモンを Unix で起動するときの推奨される方法です。mysqld_safe により、エラー発生時にサーバを再起動したり、ランタイム情報をログファイルに記録するなどのセーフティ機能が加わります。

注意: MySQL 4.0 より前は、mysqld_safe は safe_mysqld という名前でした。下位互換性を維持するため、しばらくの間、MySQL バイナリディストリビューションには mysqld_safe へのシンボリックリンクとして safe_mysqld が含められています。

--mysqld=# または --mysqld-version=# を使用しない場合、mysqld_safe は、mysqld-max という名前の実行可能ファイルがあればこれを使用します。このファイルがなければ、mysqld_safe は mysqld を開始します。これにより、mysqld の代わりに mysqld-max が使用されるかどうかのテストを簡単に実行できます。mysqld-max を mysqld のある場所にコピーするだけで、前者が使用されます。

通常、mysqld_safe スクリプトは編集しないでください。代わりに、`my.cnf' ファイルの [mysqld_safe] セクションの mysqld_safe にオプションを設定します。mysqld_safe は、オプション設定ファイルの [mysqld]、[server]、[mysqld_safe] の各セクションからすべてのオプションを読み取ります（下位互換性のため、[safe_mysqld] セクションからもオプションが読み取られます）。 「4.1.2 `my.cnf' オプション設定ファイル」 節 参照 。

注意: mysqld_safe に対するコマンドラインオプションはすべて mysqld に渡されます。mysqld がサポートしていないオプションを mysqld_safe で使用するには、オプション設定ファイルでそのオプションを指定する必要があります。

mysqld_safe のオプションのほとんどは、mysqld のオプションと同じです。 「4.1.1 mysqld コマンドラインオプション」 節 参照 。

mysqld_safe は、以下のオプションをサポートします。

--basedir=path
--core-file-size=#
mysqld が作成できるコアファイルのサイズ。ulimit -c に渡される。
--datadir=path
--defaults-extra-file=path
--defaults-file=path
--err-log=path（4.0 で廃止。代わりに --log-error を使用すること）
--log-error=path
上記ファイルにエラーログを書き込む。 「4.10.1 エラーログ」 節 参照 。
--ledir=path
mysqld のパス。
--log=path
--mysqld=mysqld-version
ledir ディレクトリ内にある起動する mysqld バージョンの名前。
--mysqld-version=version
--mysqld= と同様であるが、ここでは mysqld のサフィックスのみ指定する。 たとえば、--mysqld-version=max を使用すると、mysqld_safe は ledir/mysqld-max バージョンを起動する。--mysqld-version の引数が空白の場合、ledir/mysqld が使用される。
--nice=#（MySQL 4.0.14 で追加）
--no-defaults
--open-files-limit=#
mysqld が開くことのできるファイルの数。ulimit -n に渡される。注意: これを正常に機能させるには、mysqld_safe を root として起動する必要がある。
--pid-file=path
--port=#
--socket=path
--timezone=#
タイムゾーン（TZ）変数を、このパラメータの値に設定する。
--user=#

mysqld_safe スクリプトは、MySQL のソースバージョンまたはバイナリバージョンのどちらでインストールされたサーバでも起動できるように記述されています。サーバが多少異なる場所にインストールされていても問題ありません。mysqld_safe は、以下のいずれかの条件が満たされていることを必要とします。

mysqld_safe はその作業ディレクトリに相対してサーバとデータベースを探すため、MySQL インストールディレクトリから mysqld_safe を開始するのであれば、MySQL のバイナリディストリビューションはどこにでもインストールできます。

 
shell> cd mysql_installation_directory
shell> bin/mysqld_safe &

MySQL インストールディレクトリから起動しても mysqld_safe が失敗する場合、システムにとって正しい mysqld のパスとパス名オプションが使用されるように修正します。注意: MySQL をアップグレードすると、mysqld_safe の修正バージョンは上書きされます。再インストールできるように、編集バージョンのコピーを取っておいてください。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.8.3 mysqld_multi（複数の MySQL サーバを管理するプログラム）

mysqld_multi は、さまざまな Unix ソケットおよび TCP/IP ポートをリッスンする複数の mysqld プロセスを管理するためのプログラムです。

このプログラムは、[mysqld#] という名前のグループを `my.cnf'（または --config-file=... オプションで指定されたファイル）から検索します。ここで、# は 1 で始まる任意の正の数です。この番号は、以下の説明ではオプショングループ番号、または GNR と呼びます。グループ番号はオプショングループを識別し、起動したり、停止したり、またはステータス情報を取得するサーバを指定する mysqld_multi の引数として使用します。これらのグループに含まれるオプションは、mysqld の起動に使用される通常の [mysqld] グループと同じです（ 「2.4.3 MySQL を自動的に起動および停止する」 などを参照してください）。ただし、mysqld_multi では、各グループに、各 mysqld プロセスで使用されるポートやソケットなどを指定するオプションが含まれていることが必要です。

mysqld_multi は、以下の構文で起動します。

 
   mysqld_multi [OPTIONS] {start|stop|report} [GNR,GNR,GNR...]
か mysqld_multi [OPTIONS] {start|stop|report} [GNR-GNR,GNR,GNR-GNR,...]

各 GNR は、オプショングループ番号を表します。任意の GNR を開始、停止、または報告でき、複数の GNR を同時に開始、停止、または報告することもできます。オプション設定ファイルの設定例を表示するには、以下のコマンドを実行します。

 
shell> mysqld_multi --example

リスト内の GNR の値はコンマで区切ったり、ダッシュ記号で結合できます。結合の場合、GNR1-GNR2 間のすべての GNR が対象になります。GNR 引数を指定しなかった場合、リスト内のすべてのグループが起動、停止、または報告されます。注意: GNR リストには空白スペースを使用できません。空白スペースを挿入すると、スペースの後は無視されます。

mysqld_multi は、以下のオプションをサポートします。

--config-file=...
代替設定ファイル。注意: これは、このプログラムのオプション（[mysqld_multi] グループ）には影響せず、[mysqld#] グループにのみ影響する。このオプションがない場合、通常の `my.cnf' ファイルからすべてが検索される。
--example
オプション設定ファイル例を表示する。
--help
ヘルプを出力して終了する。
--log=...
ログファイル。ログファイルの完全パスと名前。注意: このファイルが存在していれば、すべてがログファイルに記録される。
--mysqladmin=...
サーバのシャットダウンに使用する mysqladmin バイナリ。
--mysqld=...
使用する mysqld バイナリ。注意: このオプションに mysqld_safe を指定することもできる。このオプションは、mysqld に渡される。環境変数 PATH が mysqld を指定していることを確認するか、mysqld_safe を修正する。
--no-log
ログをログファイルではなく、stdout に書き込む。デフォルトではログファイルが有効になっている。
--password=...
mysqladmin のユーザのパスワード。
--tcp-ip
Unix ソケットではなく、TCP/IP ポートで各 MySQL サーバに接続する。これは、サーバの停止と報告に影響する。ソケットファイルがなくてもサーバはまだ実行可能であるが、TCP/IP ポート経由のアクセスに限られる。デフォルトでは、Unix ソケットが使用される。
--user=...
mysqladmin の MySQL ユーザ。
--version
バージョン番号を出力して終了する。

mysqld_multi に関する補足コメント

「4.2 同じマシン上で複数の MySQL サーバを実行する」 節 参照 。

以下、mysqld_multi の設定が含まれる設定ファイルの例です。

 
# This file should probably be in your home dir (~/.my.cnf) or /etc/my.cnf
# Version 2.1 by Jani Tolonen

[mysqld_multi]
mysqld     = /usr/local/bin/mysqld_safe
mysqladmin = /usr/local/bin/mysqladmin
user       = multi_admin
password   = multipass

[mysqld2]
socket     = /tmp/mysql.sock2
port       = 3307
pid-file   = /usr/local/mysql/var2/hostname.pid2
datadir    = /usr/local/mysql/var2
language   = /usr/local/share/mysql/english
user       = john

[mysqld3]
socket     = /tmp/mysql.sock3
port       = 3308
pid-file   = /usr/local/mysql/var3/hostname.pid3
datadir    = /usr/local/mysql/var3
language   = /usr/local/share/mysql/swedish
user       = monty

[mysqld4]
socket     = /tmp/mysql.sock4
port       = 3309
pid-file   = /usr/local/mysql/var4/hostname.pid4
datadir    = /usr/local/mysql/var4
language   = /usr/local/share/mysql/estonia
user       = tonu

[mysqld6]
socket     = /tmp/mysql.sock6
port       = 3311
pid-file   = /usr/local/mysql/var6/hostname.pid6
datadir    = /usr/local/mysql/var6
language   = /usr/local/share/mysql/japanese
user       = jani

「4.1.2 `my.cnf' オプション設定ファイル」 節 参照 。

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top ] [Contents ] [Index] [ ? ]

4.8.4 myisampack（MySQL 圧縮読み取り専用テーブルジェネレータ）

myisampack は MyISAM テーブルの圧縮に、pack_isam は ISAM テーブルの圧縮に使用します。ISAM テーブルは廃止されているため、ここでは myisampack に限って話を進めますが、myisampack について説明することはすべて、pack_isam にも当てはまります。

myisampack は、テーブル内の各カラムを個別に圧縮します。テーブルを開いたとき、カラムを展開するための情報がメモリに読み込まれます。これにより、個々のレコードにアクセスする際のパフォーマンスが向上します。この場合、Stacker を MS-DOS で使用するときのような大きなディスクブロックではなく、1 つのレコードだけを解凍するだけで済みます。 通常、myisampack はデータファイルを 40% 〜 70% 圧縮します。

MySQL は、圧縮テーブルでメモリマッピング（mmap()）を使用し、mmap() が機能しない場合は、通常のファイルの読み取り/書き込み使用法に戻ります。

以下に注意してください。

myisampack は以下のコマンドで起動します。

 
shell> myisampack [options] filename ...

各ファイル名は、インデックス（`.MYI'）ファイル名になっていることが必要です。データディレクトリがカレントディレクトリでなければ、ファイルのパスを指定してください。`.MYI' 拡張子は省略可能です。

myisampack は、以下のオプションをサポートします。

-b, --backup
テーブルのバックアップを tbl_name.OLD として作成する。

-#, --debug=debug_options
デバッグログを出力する。debug_options 文字列には、'd:t:o,filename' がよく使用される。

-f, --force
テーブルが大きくなってしまう場合、テンポラリファイルが存在する場合でもテーブルのパックを強制する。myisampack は、テーブルの圧縮中、`tbl_name.TMD' という名前のテンポラリファイルを生成する。myisampack を強制終了した場合、`.TMD' ファイルが削除されない場合がある。通常、`tbl_name.TMD' があれば、myisampack はエラーを出力して終了する。--force を使用すると、テンポラリファイルの有無に関わらず myisampack はテーブルをパックする。

-?, --help
ヘルプメッセージを表示して終了する。

-j big_tbl_name, --join=big_tbl_name
コマンドラインで指定されたすべてのテーブルを結合して 1 つのテーブル big_tbl_name にする。結合するテーブルはすべて、同一（同じカラム名、同じ型、同じインデックスなど）のテーブルであることが必要である。

-p #, --packlength=#
レコード長保存サイズをバイト単位で指定する。値は 1、2、または 3 であることが必要。myisampack は、すべてのレコードを 1、2、または 3 バイトの長さポインタで保存する。ほとんどの場合、myisampack はファイルをパックする前に、正しい長さを判断できるが、パック中にさらに短くてもよいことを認識する場合がある。この場合、myisampack は、次回同じファイルをパックするときに、レコード長を短くできるというメモを出力する。

-s, --silent
サイレントモード。エラー発生時のみ出力する。

-t, --test
実際にはテーブルをパックせず、パックテストのみ実行する。

-T dir_name, --tmp_dir=dir_name
テンポラリテーブルを書き込むディレクトリを指定する。

-v, --verbose
冗長モード。パックの進捗および結果に関する情報を出力する。

-V, --version
バージョン情報を表示して終了する。

-w, --wait

テーブルが使用中の場合、待機して再試行する。mysqld サーバが --skip-external-locking オプションで起動しいる場合、パッキングプロセス中にテーブルが更新される可能性があれば、myisampack を使用すべきではない。

以下のコマンドシ