通常、mysqld オプションはオプション設定ファイルから管理してください。 See 項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. 「レプリケーションスタートアップオプション」 を参照してください。

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

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

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

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

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

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

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

MySQL は、オプション設定ファイルを上記の順序で読み取ろうとします。複数のオプション設定ファイルが存在する場合、後で読み取られたファイルに指定されているオプションの方が、先に読み取られたファイル内の同一オプションより優先されます。コマンドラインで指定されたオプションは、オプション設定ファイルで指定されたオプションよりも優先されます。オプションによっては、環境変数を使用して指定できるものもあります。 コマンドラインまたはオプション設定ファイルで指定されたオプションの方が、環境変数値よりも優先されます。 See 付録?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 オプション付きでそのプログラムを実行してください。

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

[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 プログラムはすべて、以下のオプションをサポートします。

注意: これらのオプションは、コマンド行の最初に置く必要があります。ただし、--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

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

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

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

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

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

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

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

複数のサーバを 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 スクリプトを使用して複数のサーバを開始することもできます。 See 項4.8.3. 「mysqld_multi（複数の MySQL サーバを管理するプログラム）」。

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

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

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

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

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 サポートも利用できます。 See 項4.4.10. 「安全な接続の使用」。

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

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

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 を使用できません。 See 項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

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

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

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 の各テーブルを使用します。これらの権限テーブルのフィールドを以下に示します。

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

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

スコープフィールドは、テーブルの各登録の範囲を特定します。たとえば、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: 要求確認」 を参照してください。

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

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

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

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

注意: 管理者権限（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 テーブルだけを使用してアクセスをチェックします。テーブルまたはカラムレベルの権限はチェックしません。

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

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

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

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

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

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

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 のようなコマンドを使用してパスワードを知ることができてしまいます。 See 項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 つあります。

ユーザが 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 フィールドでは 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 で導入）を使用して、その接続に実際に一致しているユーザとホストの組み合わせを確認できます。 See 項6.3.6.2. 「その他の各種関数」。

接続が確立すると、サーバは段階 2 に移行します。その接続での要求ごとに、サーバはユーザにそれを実行できる権限があるかどうかを、操作タイプに基づいてチェックします。ここで、権限テーブルの権限フィールドが関係してきます。権限は、user、db、host、tables_priv、columns_priv のテーブルで設定できます。権限テーブルの設定は、GRANT コマンドと REVOKE コマンドで行います。 See 項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 テーブルでチェックします。

サーバは、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 などを使用）、アクセス権限が目的どおりに設定されていることを確認してください。

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 の違いは以下のとおりです。

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

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 つのレベルの権限を与えたり取り消すことができます。

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

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

CREATE TEMPORARY TABLES、EXECUTE、LOCK TABLES、REPLICATION ...、SHOW DATABASES、および SUPER は、バージョン 4.0.2 で新しく導入された権限です。4.0.2 にアップグレードした後でこれらの権限を使用するには、mysql_fix_privilege_tables スクリプトを実行する必要があります。 See 項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 コマンドを使用することもできます。 See 項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（デフォルト）の場合、そのユーザに制限はないということです。 See 項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 を実行してサーバに権限テーブルを再読み込みさせる必要があります。 See 項4.4.3. 「権限の変更はいつ反映されるか」。

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

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

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

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

MySQL サーバにコマンドラインクライアントでログインする場合は、--password=your-password でパスワードを指定してください。 See 項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 の内部では、パスワード長に制限はありません。

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

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

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

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

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

注意: Windows のデフォルト権限とは異なります。 See 項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 ディストリビューションからコピーし直してください。

ユーザの追加には、2 つの方法があります。GRANT ステートメントを使用する方法と、MySQL 権限テーブルを直接操作する方法です。正確でエラーが発生しにくい GRANT ステートメントの使用を推奨します。 See 項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 人の新規ユーザが追加されます。

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;

DROP USER user_name

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

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

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

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

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

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 テーブルに含まれていることが必要です。

ほとんどの場合において、ユーザとパスワードの設定には GRANT を使用します。以下の方法は上級ユーザ対象です。 See 項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 のパスワード暗号化とは異なります。 See 項4.4.2. 「MySQL のユーザ名とパスワード」。

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

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

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

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

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

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

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. 「バイナリログ」 を参照してください。

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

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

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

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

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

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

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

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

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

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

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

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

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 テーブルでは、キー統計が更新されます。このコマンドは、以下のカラムで構成されるテーブルを返します。

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

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

動的サイズの 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 で報告される問題の中には、自動的に修正されないものがあります。

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 を使用する必要がなくなるようにしてください。 See 項A.4.1. 「MySQL が何度もクラッシュする場合に行うこと」。 See 項7.1.3. 「MyISAM テーブルの問題」。

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

注意: このステートメントは、修復した各テーブルに関する多くの情報レコードを生成します。 正常な場合、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）を使用しない限り、このコマンドはバイナリログに書き込まれます。

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

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

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

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

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

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

shell> myisamchk [options] tbl_name

shell> myisamchk *.MYI

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

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

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

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

shell> myisamchk -r tbl_name

MySQL バージョン 3.23.13 以降、CHECK TABLE コマンドを使用して MyISAM テーブルをチェックできるようになりました。See 項4.5.4. 「CHECK TABLE 構文」。 テーブルの修復は REPAIR TABLE コマンドで行えます。 See 項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

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

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 圧縮読み取り専用テーブルジェネレータ）」 を参照してください。

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 およびInnoDBテーブルにのみ有効です。BDB テーブルでは、OPTIMIZE TABLE は現在 ANALYZE TABLE にマップされます。 See 項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）を使用していない限り、バイナリログに記録されます。

ANALYZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_name[,tbl_name...]

テーブルのキー分布を分析して保存します。分析中、テーブルは読み取りロックされます。このコマンドは、MyISAM テーブルと BDB テーブルに対して使用できます。

これは、テーブルに対して myisamchk -a を実行するのと同じです。

定数を条件としない結合を実行する場合、MySQL は保存されたキー分布を使用して、テーブルの結合順序を決定します。

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

保存されたキー分布をチェックするには、SHOW INDEX コマンドを使用します。 See 項4.6.8.1. 「データベース、テーブル、カラム、およびインデックスに関する情報の取得」。

前回の ANALYZE TABLE コマンドを実行した後でテーブルが変更されていない場合、テーブルに対して再度分析は実行されません。

MySQL 4.1.1 より前のバージョンを使用している場合、ANALYZE コマンドはバイナリログに記録されません。MySQL 4.1.1 以降を使用している場合は、オプションの NO_WRITE_TO_BINLOG キーワード（またはそのエイリアスの LOCAL）を使用していない限り、バイナリログに記録されます。

CHECKSUM TABLE tbl_name[,tbl_name ...] [ QUICK | EXTENDED ]

テーブルのチェックサムを報告します。QUICK を指定した場合、現時点のテーブルのチェックサムが報告されます。または、テーブルがチェックサムをサポートしていない場合は NULL が返されます。この処理時間は非常に短くて済みます。EXTENDED モードでは、テーブル全体がレコードごとに読み取られ、チェックサムが計算されます。大きなテーブルの場合は時間がかかります。デフォルトでは（QUICK でも EXTENDED でもない場合）、テーブルがチェックサムをサポートしていれば、現時点のチェックサムが返され、サポートしていなければ、テーブルがスキャンされます。

このコマンドは、MySQL 4.1.1 で導入されました。

FLUSH [LOCAL | NO_WRITE_TO_BINLOG] flush_option [,flush_option] ...

MySQL が使用している内部キャッシュを消去するには、FLUSH コマンドを使用します。FLUSH を実行するには、RELOAD 権限が必要です。

flush_option には、以下のいずれかを指定できます。

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 コマンドも参照してください。 See 項4.6.5. 「RESET 構文」。

RESET reset_option [,reset_option] ...

RESET コマンドは設定をリセットします。FLUSH コマンドのより強力なバージョンとしても機能します。 See 項4.6.4. 「FLUSH 構文」。

RESET を実行するには、RELOAD 権限が必要です。

PURGE {MASTER|BINARY} LOGS TO binlog_name
PURGE {MASTER|BINARY} LOGS BEFORE date

このコマンドは、指定したバイナリログまたは指定日より前のバイナリログをすべて削除する場合に使用します。 See 項4.11.7. 「マスタサーバを制御する SQL ステートメント」。

PURGE MASTER LOGS のシノニムとして PURGE BINARY LOGS が MySQL 4.1.1 から利用可能になっています。

KILL thread_id

mysqld の各接続はスレッドごとに行われます。SHOW PROCESSLIST コマンドで、どのスレッドが使用されているか知ることができます。また、KILL thread_id コマンドで、スレッドを強制終了できます。

PROCESS 権限があれば、すべてのスレッドを照会することができます。 SUPER 権限があれば、すべてのスレッドを強制終了できます。 上記の権限がない場合は、自分のスレッドだけ照会および強制終了できます。

mysqladmin processlist コマンドおよび mysqladmin kill コマンドでも、スレッドを確認および強制終了できます。

注意: 現在のところ、組み込み MySQL サーバライブラリでは KILL を使用できません。組み込みサーバは、ホストアプリケーションのスレッド内部で実行するだけで、独自の接続スレッドは作成しません。

KILL を実行すると、スレッド固有の kill flag がスレッドに設定されます。

キルフラグは一定間隔でチェックされるため、多くの場合、スレッドが終了するまでにしばらく時間がかかります。

   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 の ‘%’ および ‘_’ のワイルドカード文字を使用できます。

mysql> SHOW INDEX FROM mytable FROM mydb;
mysql> SHOW INDEX FROM mydb.mytable;

SHOW TABLE STATUS [FROM db_name] [LIKE wild]

+--------------------------+------------+
| 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      |
+--------------------------+------------+

SHOW [GLOBAL | SESSION] VARIABLES [LIKE wild]

+---------------------------------+------------------------------+
| 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                        |
+---------------------------------+------------------------------+