サーバーが使用する値を、コンパイル済みのデフォルト値と、そのサーバーが読み取るオプションファイルに基づいて表示するには、次のコマンドを使用します:

mysqld --verbose --help

コンパイルされたデフォルト値のみに基づいてサーバーが使用する値を表示し、オプションファイルの設定を無視するには、次のコマンドを使用します:

mysqld --no-defaults --verbose --help

実行中のサーバーで使用されている現在の値を表示するには、SHOW VARIABLES ステートメントまたはパフォーマンススキーマシステム変数テーブルを使用します。 セクション27.12.14「パフォーマンススキーマシステム変数テーブル」を参照してください。

セクション5.1.9「システム変数の使用」では、システム変数値の設定および表示の構文について説明します。

セクション5.1.9.2「動的システム変数」では、実行時に設定できる変数を一覧表示しています。

システム変数の調整に関する情報は、セクション5.1.1「サーバーの構成」を参照してください。

セクション15.14「InnoDB の起動オプションおよびシステム変数」では、InnoDB システム変数を一覧表示しています。

セクション23.3.3.9.2「NDB Cluster システム変数」 では、NDB Cluster に固有のシステム変数を一覧表示します。

レプリケーションに固有のサーバーシステム変数については、セクション17.1.6「レプリケーションおよびバイナリロギングのオプションと変数」を参照してください。

activate_all_roles_on_login

ユーザーがサーバーにログインしたときに、付与されたすべてのロールの自動アクティブ化を有効にするかどうか:

付与されるロールには、ユーザーに明示的に付与されるロールと、mandatory_roles システム変数値で指定されるロールが含まれます。

activate_all_roles_on_login は、ログイン時、および定義者コンテキストで実行されるストアドプログラムおよびビューの実行開始時にのみ適用されます。 セッション内のアクティブなロールを変更するには、SET ROLE を使用します。 ストアドプログラムのアクティブなロールを変更するには、プログラム本体で SET ROLE を実行する必要があります。

admin_address

管理ネットワークインタフェースで TCP/IP 接続をリスニングする IP アドレス (セクション5.1.12.1「接続インタフェース」 を参照)。 デフォルトの admin_address 値はありません。 この変数が起動時に指定されない場合、サーバーは管理インタフェースを維持しません。 サーバーには、通常の (非管理) クライアント TCP/IP 接続を構成するための bind_address システム変数もあります。 セクション5.1.12.1「接続インタフェース」を参照してください。

admin_address が指定されている場合、その値は次の要件を満たす必要があります:

IP アドレスは、IPv4 または IPv6 アドレスとして指定できます。 値がホスト名の場合、サーバーは名前を IP アドレスに解決し、そのアドレスにバインドします。 ホスト名が複数の IP アドレスに解決される場合、サーバーは最初の IPv4 アドレス (存在する場合) または最初の IPv6 アドレスを使用します。

サーバーはさまざまなタイプのアドレスを次のように処理します。

アドレスのネットワークネームスペースの指定には、次のルールが適用されます:

ネットワークネームスペースの詳細は、セクション5.1.14「ネットワークネームスペースのサポート」 を参照してください。

アドレスへのバインドが失敗した場合、サーバーはエラーを生成し、起動しません。

admin_address システム変数は、サーバーを通常のクライアント接続のアドレスにバインドする bind_address システム変数と似ていますが、次の点が異なります:

admin_port

管理ネットワークインタフェースでの接続に使用する TCP/IP ポート番号 (セクション5.1.12.1「接続インタフェース」 を参照)。 この変数を 0 に設定すると、デフォルト値が使用されます。

admin_address が指定されていない場合、サーバーは管理ネットワークインタフェースを保持しないため、admin_port を設定しても効果はありません。

admin_ssl_ca

admin_ssl_ca システム変数は ssl_ca と似ていますが、メイン接続インタフェースではなく管理接続インタフェースに適用される点が異なります。 管理インタフェースの暗号化サポートの構成の詳細は、暗号化された接続に対する管理インタフェースのサポート を参照してください。

admin_ssl_capath

admin_ssl_capath システム変数は ssl_capath と似ていますが、メイン接続インタフェースではなく管理接続インタフェースに適用される点が異なります。 管理インタフェースの暗号化サポートの構成の詳細は、暗号化された接続に対する管理インタフェースのサポート を参照してください。

admin_ssl_cert

admin_ssl_cert システム変数は ssl_cert と似ていますが、メイン接続インタフェースではなく管理接続インタフェースに適用される点が異なります。 管理インタフェースの暗号化サポートの構成の詳細は、暗号化された接続に対する管理インタフェースのサポート を参照してください。

admin_ssl_cipher

admin_ssl_cipher システム変数は ssl_cipher と似ていますが、メイン接続インタフェースではなく管理接続インタフェースに適用される点が異なります。 管理インタフェースの暗号化サポートの構成の詳細は、暗号化された接続に対する管理インタフェースのサポート を参照してください。

admin_ssl_crl

admin_ssl_crl システム変数は ssl_crl と似ていますが、メイン接続インタフェースではなく管理接続インタフェースに適用される点が異なります。 管理インタフェースの暗号化サポートの構成の詳細は、暗号化された接続に対する管理インタフェースのサポート を参照してください。

admin_ssl_crlpath

admin_ssl_crlpath システム変数は ssl_crlpath と似ていますが、メイン接続インタフェースではなく管理接続インタフェースに適用される点が異なります。 管理インタフェースの暗号化サポートの構成の詳細は、暗号化された接続に対する管理インタフェースのサポート を参照してください。

admin_ssl_key

admin_ssl_key システム変数は ssl_key と似ていますが、メイン接続インタフェースではなく管理接続インタフェースに適用される点が異なります。 管理インタフェースの暗号化サポートの構成の詳細は、暗号化された接続に対する管理インタフェースのサポート を参照してください。

admin_tls_ciphersuites

admin_tls_ciphersuites システム変数は tls_ciphersuites と似ていますが、メイン接続インタフェースではなく管理接続インタフェースに適用される点が異なります。 管理インタフェースの暗号化サポートの構成の詳細は、暗号化された接続に対する管理インタフェースのサポート を参照してください。

admin_tls_version

admin_tls_version システム変数は tls_version と似ていますが、メイン接続インタフェースではなく管理接続インタフェースに適用される点が異なります。 管理インタフェースの暗号化サポートの構成の詳細は、暗号化された接続に対する管理インタフェースのサポート を参照してください。

authentication_windows_log_level

この変数は、authentication_windows Windows 認証プラグインが使用可能で、デバッグコードが有効な場合のみ使用できます。 セクション6.4.1.6「Windows プラガブル認証」を参照してください。

この変数は、Windows 認証プラグインのロギングレベルを設定します。 次の表は、許可される値を示しています。

authentication_windows_use_principal_name

この変数は、authentication_windows Windows 認証プラグインが使用可能な場合のみ使用できます。 セクション6.4.1.6「Windows プラガブル認証」を参照してください。

InitSecurityContext() 関数を使用して認証するクライアントは、接続するサービスを識別する文字列を提供する必要があります (targetName)。 MySQL は、サーバーが実行するアカウントの主体名 (UPN) を使用します。 UPN は user_id@computer_name という形式で、使用される場所に登録される必要はありません。 この UPN は、認証ハンドシェイクの最初にサーバーによって送信されます。

この変数は、サーバーが初期チャレンジで UPN を送信するかどうかを制御します。 デフォルトでは、変数は有効になっています。 セキュリティー上の理由から、サーバーアカウント名をクリアテキストとしてクライアントに送信しないように無効にできます。 変数が無効な場合、サーバーは最初のチャレンジで常に 0x00 バイトを送信し、クライアントは targetName を指定せず、結果として NTLM 認証が使用されます。

サーバーが UPN の取得に失敗した場合 (主に Kerberos 認証をサポートしていない環境で発生)、UPN はサーバーによって送信されず、NTLM 認証が使用されます。

自動コミット

自動コミットモード。 1 に設定された場合、テーブルへのすべての変更はすぐに有効になります。 0 に設定した場合、COMMIT を使用してトランザクションを受け入れるか、ROLLBACK でトランザクションをキャンセルする必要があります。 autocommit が 0 で、これを 1 に変更した場合、MySQL はオープン中のすべてのトランザクションの自動的な COMMIT を実行します。 トランザクションを始める別の方法は、START TRANSACTION または BEGIN ステートメントを利用する方法です。 セクション13.3.1「START TRANSACTION、COMMIT および ROLLBACK ステートメント」を参照してください。

デフォルトでは、クライアント接続は autocommit を 1 に設定して開始されます。 デフォルト 0 でクライアントを開始させるには、--autocommit=0 オプションを使用してサーバーを開始することによって、グローバルな autocommit 値を設定します。 オプションファイルを使用して変数を設定するには、次の行を含めます。

[mysqld]
autocommit=0

automatic_sp_privileges

この変数の値が 1 (デフォルト) のとき、ユーザーがルーチンを実行して変更したりドロップしたりできない場合、サーバーは自動的に EXECUTE および ALTER ROUTINE の権限をストアドルーチンの作成者に付与します。 (ルーチンをドロップするには ALTER ROUTINE 権限が必要です。) ルーチンがドロップされると、サーバーはそれらの権限を作成者から自動的にドロップします。 automatic_sp_privileges が 0 の場合、サーバーはこれらの権限を自動的に追加またはドロップしません。

ルーチンの作成者は、ルーチンの CREATE ステートメントを実行するために使用されるアカウントです。 これは、ルーチン定義で DEFINER として名前が指定されているアカウントと同じでないことがあります。

--skip-new を使用して mysqld を起動すると、automatic_sp_privileges は OFF に設定されます。

セクション25.2.2「ストアドルーチンと MySQL 権限」も参照してください。

auto_generate_certs

この変数は、サーバーが SSL キーおよび証明書ファイルをデータディレクトリに自動生成するかどうかを制御します (まだ存在しない場合)。

起動時に、auto_generate_certs システム変数が有効で、--ssl 以外の SSL オプションが指定されておらず、サーバー側の SSL ファイルがデータディレクトリから欠落している場合、サーバーはサーバー側およびクライアント側の SSL 証明書とキーファイルをデータディレクトリに自動的に生成します。 これらのファイルにより、SSL を使用したセキュアなクライアント接続が可能になります。セクション6.3.1「暗号化接続を使用するための MySQL の構成」 を参照してください。

ファイル名や特性など、SSL ファイルの自動生成の詳細は、セクション6.3.3.1「MySQL を使用した SSL および RSA 証明書とキーの作成」 を参照してください

sha256_password_auto_generate_rsa_keys および caching_sha2_password_auto_generate_rsa_keys システム変数は関連していますが、暗号化されていない RSA 接続を使用したセキュアなパスワード交換に必要な RSA キーペアファイルの自動生成を制御します。

avoid_temporal_upgrade

この変数は、ALTER TABLE が、5.6.4 より前の形式 (TIME、DATETIME および TIMESTAMP カラムで小数秒精度をサポートしない) で検出された一時カラムを暗黙的にアップグレードするかどうかを制御します。 このようなカラムをアップグレードするには、テーブルの再構築が必要です。これにより、操作に適用される可能性のある高速変更が使用されなくなります。

この変数はデフォルトでは無効になっています。 これを有効にすると、ALTER TABLE は時間的カラムを再構築しないため、可能な高速変更を利用できます。

この変数は非推奨です。将来の MySQL リリースで削除される予定です。

back_log

MySQL で保持できる未処理の接続リクエストの数。 これはメインの MySQL スレッドが非常に短時間で非常に多くの接続リクエストを受け取る場合に効果をあらわします。 次に、メインスレッドが接続を検査し新規スレッドを開始するまで (非常に短いですが) 少し時間がかかります。 back_log 値は、MySQL が新規リクエストへの回答を一時的に停止するまでの短い時間に、スタック可能なリクエストの数を示します。 短い時間に大量の接続が予想される場合にかぎり、これを増加する必要があります。

つまり、この値は着信 TCP/IP 接続の listen キューのサイズです。 使用しているオペレーティングシステムには、このキューのサイズについて独自の制限があります。 UNIX listen() システムコールのマニュアルページに、詳細情報があります。 この変数の最大値については OS のドキュメントを確認してください。back_log をオペレーティングシステムの制限を超える設定はできません。

デフォルト値は max_connections の値です。これにより、許可されたバックログを最大許容接続数に調整できます。

basedir

MySQL インストールベースディレクトリへのパス。

big_tables

有効にすると、サーバーはすべての一時テーブルをメモリーではなくディスクに格納します。 これにより、大規模な一時テーブルを必要とする SELECT 操作のほとんどの The table tbl_name is full エラーが回避されますが、インメモリーテーブルで十分なクエリーが遅くなります。

新しい接続のデフォルト値は OFF です (インメモリー一時テーブルを使用)。 通常、この変数を有効にする必要はありません。 インメモリー internal 一時テーブルが TempTable ストレージエンジンによって管理され (デフォルト)、TempTable ストレージエンジンが占有できるメモリーの最大量を超えると、TempTable ストレージエンジンはディスク上の一時ファイルへのデータの格納を開始します。 インメモリー一時テーブルが MEMORY ストレージエンジンによって管理される場合、インメモリーテーブルは必要に応じてディスクベースのテーブルに自動的に変換されます。 詳細は、セクション8.4.4「MySQL での内部一時テーブルの使用」を参照してください。

bind_address

MySQL サーバーは、1 つ以上のネットワークソケットで TCP/IP 接続をリスニングします。 各ソケットは 1 つのアドレスにバインドされますが、1 つのアドレスを複数のネットワークインタフェースにマップできます。 サーバーが TCP/IP 接続をリスニングする方法を指定するには、サーバーの起動時に bind_address システム変数を設定します。 サーバーには、専用インタフェースでの管理接続を可能にする admin_address システム変数もあります。 セクション5.1.12.1「接続インタフェース」を参照してください。

bind_address が指定されている場合、その値は次の要件を満たす必要があります:

IP アドレスは、IPv4 または IPv6 アドレスとして指定できます。 ホスト名である値の場合、サーバーは名前を IP アドレスに解決し、そのアドレスにバインドします。 ホスト名が複数の IP アドレスに解決される場合、サーバーは最初の IPv4 アドレス (存在する場合) または最初の IPv6 アドレスを使用します。

サーバーはさまざまなタイプのアドレスを次のように処理します。

アドレスのネットワークネームスペースの指定には、次のルールが適用されます:

ネットワークネームスペースの詳細は、セクション5.1.14「ネットワークネームスペースのサポート」 を参照してください。

いずれかのアドレスへのバインドが失敗した場合、サーバーはエラーを生成し、起動しません。

例:

bind_address が単一の値 (ワイルドカードまたは非ワイルドカード) に名前を付けると、サーバーは単一のソケットでリスニングし、ワイルドカードアドレスは複数のネットワークインタフェースにバインドできます。 bind_address が複数の値のリストに名前を付けると、サーバーは値ごとに 1 つのソケットをリスニングし、各ソケットは単一のネットワークインタフェースにバインドされます。 ソケットの数は、指定された値の数と線形です。 オペレーティングシステムの connection-acceptance 効率によっては、長い値のリストで TCP/IP 接続を受け入れるためのパフォーマンスペナルティが発生する場合があります。

リスニングソケットおよびネットワークネームスペースファイルにはファイル記述子が割り当てられるため、open_files_limit システム変数を増やす必要がある場合があります。

サーバーを特定のアドレスにバインドする場合は、そのアドレスへの接続に使用できる管理権限を持つアカウントが mysql.user システムテーブルに含まれていることを確認してください。 そうしないと、サーバーを停止できません。 たとえば、サーバーを * にバインドしている場合、すべての既存のアカウントを使用して接続できます。 ただし、サーバーを ::1 にバインドしている場合、そのアドレスの接続のみ受け入れます。 この場合、'root'@'::1' アカウントが mysql.user テーブルに存在することをまず確認して、サーバーに接続してシャットダウンできることをたしかめます。

block_encryption_mode

この変数は、AES などのブロックベースのアルゴリズムのブロック暗号化モードを制御します。 これは AES_ENCRYPT() および AES_DECRYPT() の暗号化に影響します。

block_encryption_mode は aes-keylen-mode 形式の値を取り、ここで keylen はビット単位の鍵の長さ、mode は暗号化モードです。 値では大文字と小文字は区別されません。 許可される keylen 値は 128、192、および 256 です。 許可される mode 値は、ECB, CBC, CFB1, CFB8, CFB128 および OFB です。

たとえば次のステートメントでは、AES 暗号化機能が 256 ビットの鍵の長さおよび CBC モードを使用します。

SET block_encryption_mode = 'aes-256-cbc';

サポートされない鍵の長さや SSL ライブラリがサポートしないモードを含む値に block_encryption_mode を設定しようとすると、エラーが発生します。

bulk_insert_buffer_size

MyISAM では、空でないテーブルにデータを追加する際に、INSERT ... SELECT、INSERT ... VALUES (...), (...), ... および LOAD DATA のバルク挿入を高速化するために、特別なツリー形式のキャッシュを使用します。 この変数は、スレッドあたりのバイト単位のキャッシュツリーのサイズを制限します。 これを 0 に設定すると、この最適化が無効になります。 デフォルトの値は 8M バイトです。

MySQL 8.0.14 では、このシステム変数のセッション値の設定は制限された操作です。 セッションユーザーには、制限付きセッション変数を設定するのに十分な権限が必要です。 セクション5.1.9.1「システム変数権限」を参照してください。

caching_sha2_password_digest_rounds

パスワード記憶域用の caching_sha2_password 認証プラグインで使用されるハッシュラウンドの数。

ハッシングラウンドの数をデフォルト値より大きくすると、増加量に関連するパフォーマンスペナルティが発生します:

caching_sha2_password_auto_generate_rsa_keys

サーバーはこの変数を使用して、RSA 秘密/公開鍵ペアファイルがまだ存在しない場合に、それらをデータディレクトリに自動生成するかどうかを決定します。

これらの条件がすべて満たされている場合、サーバーは起動時に RSA 秘密キー/公開キーのペアファイルをデータディレクトリに自動的に生成: sha256_password_auto_generate_rsa_keys または caching_sha2_password_auto_generate_rsa_keys システム変数が有効になっており、RSA オプションが指定されていません。RSA ファイルがデータディレクトリにありません。 これらのキーペアファイルを使用すると、sha256_password または caching_sha2_password プラグインによって認証されたアカウントに対して、暗号化されていない RSA 接続を使用したセキュアなパスワード交換が可能になります。セクション6.4.1.3「SHA-256 プラガブル認証」 および セクション6.4.1.2「SHA-2 プラガブル認証のキャッシュ」 を参照してください。

RSA ファイルの自動生成の詳細 (ファイル名や特性など) は、セクション6.3.3.1「MySQL を使用した SSL および RSA 証明書とキーの作成」 を参照してください

auto_generate_certs システム変数は関連していますが、SSL を使用したセキュアな接続に必要な SSL 証明書およびキーファイルの自動生成を制御します。

caching_sha2_password_private_key_path

この変数は、caching_sha2_password 認証プラグインの RSA 秘密キーファイルのパス名を指定します。 ファイル名が相対パスとして指定された場合、サーバーのデータディレクトリを基準として解釈されます。 ファイルは PEM 形式である必要があります。

caching_sha2_password の詳細は、セクション6.4.1.2「SHA-2 プラガブル認証のキャッシュ」 を参照してください。

caching_sha2_password_public_key_path

この変数は、caching_sha2_password 認証プラグインの RSA 公開キーファイルのパス名を指定します。 ファイル名が相対パスとして指定された場合、サーバーのデータディレクトリを基準として解釈されます。 ファイルは PEM 形式である必要があります。

クライアントが RSA 公開キーをリクエストする方法など、caching_sha2_password の詳細は、セクション6.4.1.2「SHA-2 プラガブル認証のキャッシュ」 を参照してください。

character_set_client

クライアントから到達するステートメントの文字セット。 この変数のセッション値は、クライアントがサーバーに接続するときにクライアントによってリクエストされる文字セットを使用して設定されます。 (多くのクライアントは、この文字セットを明示的に指定するための --default-character-set オプションをサポートします。 セクション10.4「接続文字セットおよび照合順序」も参照してください。) クライアントがリクエストする値が不明または利用できないか、サーバーがクライアントリクエストを無視するように構成されている場合、セッション値を設定するよう変数のグローバル値が使用されます。

一部の文字セットは、クライアントの文字セットとして使用できません。 これらを character_set_client 値として使用しようとすると、エラーが発生します。 許可されていないクライアント文字セットを参照してください。

character_set_connection

文字セットイントロデューサなしで指定されたリテラルおよび数値から文字列への変換に使用される文字セット。 イントロデューサについては、セクション10.3.8「文字セットイントロデューサ」 を参照してください。

character_set_database

デフォルトデータベースで使用される文字セット。 デフォルトのデータベースが変更されるたびに、サーバーはこの変数を設定します。 デフォルトデータベースが存在しない場合、変数は character_set_server と同じ値になります。

MySQL 8.0.14 では、このシステム変数のセッション値の設定は制限された操作です。 セッションユーザーには、制限付きセッション変数を設定するのに十分な権限が必要です。 セクション5.1.9.1「システム変数権限」を参照してください。

グローバル character_set_database および collation_database システム変数は非推奨です。将来のバージョンの MySQL で削除される予定です。

セッション character_set_database および collation_database システム変数への値の割当ては非推奨になり、割当てによって警告が生成されます。 MySQL の将来のバージョンでは、セッション変数にアクセスしてデフォルトデータベースのデータベース文字セットおよび照合を決定できるように、セッション変数が読取り専用になる (およびエラーを生成するために割り当てられる) ことを想定します。

character_set_filesystem

ファイルシステムの文字セット。 この変数は、LOAD DATA ステートメント、SELECT ... INTO OUTFILE ステートメント、LOAD_FILE() 関数など、ファイル名を参照する文字列リテラルを解釈するために使用されます。 このようなファイル名は、ファイルを開くよう試行する前に character_set_client から character_set_filesystem に変換されます。 デフォルト値は binary で、変換が行われないことを意味します。 マルチバイトファイル名が許可されるシステムについては、別の値が適切な場合もあります。 たとえば、システムが UTF-8 を使用してファイル名を表す場合は、character_set_filesystem を'utf8mb4'に設定します。

MySQL 8.0.14 では、このシステム変数のセッション値の設定は制限された操作です。 セッションユーザーには、制限付きセッション変数を設定するのに十分な権限が必要です。 セクション5.1.9.1「システム変数権限」を参照してください。

character_set_results

クエリー結果をクライアントに返すために使用される文字セット。 これには、カラム値、結果メタデータ (カラム名など)、エラーメッセージなどの結果データが含まれます。

character_set_server

サーバーのデフォルトの文字セット。 セクション10.15「文字セットの構成」を参照してください。 この変数を設定する場合は、文字セットの照合順序を指定するように collation_server も設定する必要があります。

character_set_system

識別子を格納するためにサーバーで使用される文字セット。 この値は常に utf8 です。

character_sets_dir

文字セットがインストールされているディレクトリ。 セクション10.15「文字セットの構成」を参照してください。

check_proxy_users

一部の認証プラグインは、プロキシユーザーマッピングを実装しています (PAM や Windows 認証プラグインなど)。 その他の認証プラグインは、デフォルトではプロキシユーザーをサポートしていません。 その中には、付与されたプロキシ権限に従って、MySQL サーバー自体がプロキシユーザーをマップするようにリクエストできるものがあります: mysql_native_password、sha256_password。

check_proxy_users システム変数が有効になっている場合、サーバーは、このようなリクエストを行う認証プラグインに対してプロキシユーザーマッピングを実行します。 ただし、サーバープロキシユーザーマッピングのサポートを利用するには、プラグイン固有のシステム変数を有効にする必要がある場合もあります:

ユーザープロキシの詳細は、セクション6.2.18「プロキシユーザー」 を参照してください。

collation_connection

接続文字セットの照合順序。collation_connection は、リテラル文字列の比較に重要です。 カラム値と文字列を比較する場合、collation_connection は関係ありません。これは、カラムには照合優先度の高い独自の照合があるためです (セクション10.8.4「式での照合の強制性」 を参照)。

collation_database

デフォルトデータベースで使用される照合。 デフォルトのデータベースが変更されるたびに、サーバーはこの変数を設定します。 デフォルトデータベースが存在しない場合、変数は collation_server と同じ値になります。

MySQL 8.0.18 では、このシステム変数のセッション値の設定は制限付き操作ではなくなりました。

グローバル character_set_database および collation_database システム変数は非推奨です。将来のバージョンの MySQL で削除される予定です。

セッション character_set_database および collation_database システム変数への値の割当ては非推奨になり、割当てによって警告が生成されます。 MySQL の将来のバージョンでは、セッション変数にアクセスしてデフォルトデータベースのデータベース文字セットおよび照合を決定できるように、セッション変数が読取り専用 (およびエラーを生成する割当て) になることを想定しています。

collation_server

サーバーのデフォルトの照合順序。 セクション10.15「文字セットの構成」を参照してください。

completion_type

トランザクション完了タイプ。 この変数は、次の表に示す値を取ることができます。 変数は、名前の値か対応する整数値のいずれかを使用して割り当てることができます。

completion_type は、START TRANSACTION または BEGIN で開始されて COMMIT または ROLLBACK で終了するトランザクションに影響します。 これは、セクション13.3.3「暗黙的なコミットを発生させるステートメント」に一覧表示されているステートメントの実行から生じる暗黙的なコミットに適用されません。 また、XA COMMIT や XA ROLLBACK に対して、あるいは autocommit=1 の場合にも適用されません。

concurrent_insert

AUTO (デフォルト) の場合、MySQL ではデータファイルの中間に空きブロックがない MyISAM テーブルに対して INSERT および SELECT ステートメントを同時に実行することが許可されます。

この変数は、次の表に示す値を取ることができます。 変数は、名前の値か対応する整数値のいずれかを使用して割り当てることができます。

--skip-new を使用して mysqld を起動すると、concurrent_insert は NEVER に設定されます。

セクション8.11.3「同時挿入」も参照してください。

connect_timeout

mysqld サーバーがハンドシェイクエラーを返すまでに接続パケットを待つ秒数。 デフォルトは 10 秒です。

「Lost connection to MySQL server at 'XXX', system error: errno」という形式のエラーがクライアントで頻繁に発生する場合、connect_timeout 値を増やすと役立つことがあります。

core_file

サーバーが予期せず終了した場合にコアファイルを書き込むかどうか。 この変数は --core-file オプションによって設定されます。

create_admin_listener_thread

管理ネットワークインタフェースでクライアント接続専用のリスニングスレッドを使用するかどうか (セクション5.1.12.1「接続インタフェース」 を参照)。 デフォルトは OFF です。つまり、メインインタフェース上の通常の接続のマネージャスレッドは、管理インタフェースの接続も処理します。

プラットフォームタイプやワークロードなどの要因によっては、この変数の一方の設定により、他方の設定よりもパフォーマンスが向上する場合があります。

admin_address が指定されていない場合、サーバーは管理ネットワークインタフェースを保持しないため、create_admin_listener_thread を設定しても効果はありません。

cte_max_recursion_depth

共通テーブル式 (CTE) の最大再帰深度。 サーバーは、この変数の値よりも多くのレベルを繰り返す CTE の実行を終了します。 詳細は、共通テーブル式の再帰の制限を参照してください。

datadir

MySQL サーバーデータディレクトリへのパス。 相対パスは、現在のディレクトリに関して解決されます。 サーバーを自動的に (つまり、事前に現在のディレクトリを認識できないコンテキストで) 起動する場合は、datadir 値を絶対パスとして指定することをお薦めします。

debug

この変数は現在のデバッグ設定を指定します。 これはデバッグサポートを使用して構築されたサーバーについてのみ使用できます。 初期値は、サーバー始動時に指定された --debug オプションのインスタンスの値から取得されます。 グローバル値とセッション値は、実行時に設定できます。

このシステム変数のセッション値の設定は制限された操作です。 セッションユーザーには、制限付きセッション変数を設定するのに十分な権限が必要です。 セクション5.1.9.1「システム変数権限」を参照してください。

+ または - で始まる値を割り当てると、値は現在の値に追加されたり現在の値から削除されたりします。

mysql> SET debug = 'T';
mysql> SELECT @@debug;
+---------+
| @@debug |
+---------+
| T       |
+---------+

mysql> SET debug = '+P';
mysql> SELECT @@debug;
+---------+
| @@debug |
+---------+
| P:T     |
+---------+

mysql> SET debug = '-P';
mysql> SELECT @@debug;
+---------+
| @@debug |
+---------+
| T       |
+---------+

詳細については、セクション5.9.4「DBUG パッケージ」を参照してください。

debug_sync

この変数は、Debug Sync 機能へのユーザーインタフェースです。 デバッグ同期を使用するには、MySQL が -DENABLE_DEBUG_SYNC=1 CMake オプションで構成されている必要があります (セクション2.9.7「MySQL ソース構成オプション」 を参照)。 Debug Sync がコンパイルされていない場合、このシステム変数は使用できません。

グローバル変数値は読み取り専用で、この機能が有効かどうかを示します。 デフォルトでは、Debug Sync は無効化されており、debug_sync の値は OFF です。 サーバーが --debug-sync-timeout=N で開始した場合 (ここで、N は 0 より大きいタイムアウト値)、Debug Sync は有効化され、debug_sync の値は ON - current signal の後にシグナル名が続いたものになります。 また、N は個々の同期点についてのデフォルトのタイムアウトになります。

セッション値は任意のユーザーが読み取ることができ、グローバル変数と同じ値を持ちます。 セッション値は、同期ポイントを制御するように設定できます。

このシステム変数のセッション値の設定は制限された操作です。 セッションユーザーには、制限付きセッション変数を設定するのに十分な権限が必要です。 セクション5.1.9.1「システム変数権限」を参照してください。

Debug Sync 機能および同期点の使用方法についての説明は、「MySQL Internals: Test Synchronization」を参照してください。

default_authentication_plugin

デフォルトの認証プラグイン 次の値を使用できます:

default_authentication_plugin の値は、サーバー操作の次の側面に影響します:

default_collation_for_utf8mb4

レプリケーションによる内部使用用。 このシステム変数は、utf8mb4 文字セットのデフォルトの照合順序に設定されます。 変数の値はソースからレプリカにレプリケートされるため、レプリカは、utf8mb4 のデフォルトの照合順序が異なるソースからのデータを正しく処理できます。 この変数は主に、MySQL 5.7 以前のレプリケーションソースサーバーから MySQL 8.0 複製サーバーへのレプリケーション、または MySQL 5.7 プライマリノードと 1 つ以上の MySQL 8.0 セカンダリノードを使用したグループレプリケーションをサポートすることを目的としています。 MySQL 5.7 の utf8mb4 のデフォルトの照合は utf8mb4_general_ci ですが、MySQL 8.0 の utf8mb4_0900_ai_ci です。 この変数は MySQL 8.0 より前のリリースには存在しないため、レプリカが変数の値を受信しない場合、ソースは以前のリリースのものとみなされ、値は以前のデフォルトの照合 utf8mb4_general_ci に設定されます。

MySQL 8.0.18 では、このシステム変数のセッション値の設定は制限付き操作ではなくなりました。

デフォルトの utf8mb4 照合は、次のステートメントで使用されます:

default_password_lifetime

この変数は、グローバル自動パスワード有効期限ポリシーを定義します。 デフォルトの default_password_lifetime 値は 0 で、パスワードの自動期限切れは無効になります。 default_password_lifetime の値が正の整数の N の場合は、許可されているパスワードの存続期間を示します。パスワードは N 日ごとに変更する必要があります。

グローバルパスワード有効期限ポリシーは、CREATE USER および ALTER USER ステートメントのパスワード有効期限オプションを使用して、個々のアカウントに対して必要に応じてオーバーライドできます。 セクション6.2.15「パスワード管理」を参照してください。

default_storage_engine

テーブルのデフォルトのストレージエンジン。 第16章「代替ストレージエンジン」を参照してください。 この変数は、永続テーブルのストレージエンジンのみを設定します。 TEMPORARY テーブルについてストレージエンジンを設定するには、default_tmp_storage_engine システム変数を設定します。

使用可能かつ有効化できるストレージエンジンを表示するには、SHOW ENGINES ステートメントまたはクエリー INFORMATION_SCHEMA ENGINES テーブルを参照してください。

サーバーの起動時にデフォルトのストレージエンジンを無効にする場合は、永続テーブルと TEMPORARY テーブルの両方のデフォルトエンジンを別のエンジンに設定する必要があります。そうしないと、サーバーは起動しません。

default_table_encryption

ENCRYPTION 句を指定せずにスキーマおよび一般テーブルスペースを作成するときに適用されるデフォルトの暗号化設定を定義します。

default_table_encryption 変数は、ユーザーが作成したスキーマおよび一般テーブルスペースにのみ適用できます。 mysql システムテーブルスペースの暗号化は制御されません。

default_table_encryption のランタイム値を設定するには、SYSTEM_VARIABLES_ADMIN および TABLE_ENCRYPTION_ADMIN 権限、または非推奨の SUPER 権限が必要です。

default_table_encryption は、SET PERSIST および SET PERSIST_ONLY 構文をサポートしています。 セクション5.1.9.3「永続化されるシステム変数」を参照してください。

詳細は、スキーマおよび一般テーブルスペースの暗号化デフォルトの定義を参照してください。

default_tmp_storage_engine

TEMPORARY テーブルのデフォルトストレージエンジン (CREATE TEMPORARY TABLE で作成されたもの)。 永続的なテーブルについてのストレージエンジンを設定するには、default_storage_engine システム変数を設定します。 可能な値については、その変数の説明も参照してください。

サーバーの起動時にデフォルトのストレージエンジンを無効にする場合は、永続テーブルと TEMPORARY テーブルの両方のデフォルトエンジンを別のエンジンに設定する必要があります。そうしないと、サーバーは起動しません。

default_week_format

WEEK() 関数について使用するデフォルトモード値。 セクション12.7「日付および時間関数」を参照してください。

delay_key_write

この変数は、遅延鍵書き込みの使用方法を指定します。 これは MyISAM テーブルにのみ適用されます。 鍵の書き込みが遅延すると、書き込み間で鍵バッファーがフラッシュされません。 セクション16.2.1「MyISAM 起動オプション」も参照してください。

この変数には、CREATE TABLE ステートメントで使用できる DELAY_KEY_WRITE テーブルオプションの処理に影響する次のいずれかの値を指定できます。

テーブルの DELAY_KEY_WRITE を有効にした場合、インデックス更新のたびにそのテーブルのキーバッファーがフラッシュされるのではなく、テーブルが閉じたときだけフラッシュされます。 これにより、キーの書込みが大幅に高速化されますが、この機能を使用する場合は、myisam_recover_options システム変数を設定してサーバーを起動することで、すべての MyISAM テーブルの自動チェックを追加する必要があります (myisam_recover_options='BACKUP,FORCE'など)。 セクション5.1.8「サーバーシステム変数」およびセクション16.2.1「MyISAM 起動オプション」を参照してください。

--skip-new を使用して mysqld を起動すると、delay_key_write は OFF に設定されます。

delayed_insert_limit

このシステム変数は非推奨 (DELAYED 挿入はサポートされていないため) であり、将来のリリースで削除される予定です。

delayed_insert_timeout

このシステム変数は非推奨 (DELAYED 挿入はサポートされていないため) であり、将来のリリースで削除される予定です。

delayed_queue_size

このシステム変数は非推奨 (DELAYED 挿入はサポートされていないため) であり、将来のリリースで削除される予定です。

disabled_storage_engines

この変数は、テーブルまたはテーブルスペースの作成に使用できないストレージエンジンを示します。 たとえば、新しい MyISAM または FEDERATED テーブルが作成されないようにするには、サーバーオプションファイルで次の行を使用してサーバーを起動します:

[mysqld]
disabled_storage_engines="MyISAM,FEDERATED"

デフォルトでは、disabled_storage_engines は空ですが (エンジンは無効化されていません)、1 つ以上のエンジンのカンマ区切りリストに設定できます (大文字と小文字は区別されません)。 値に指定されたエンジンは、CREATE TABLE または CREATE TABLESPACE を使用したテーブルまたはテーブルスペースの作成には使用できません。また、ALTER TABLE ... ENGINE または ALTER TABLESPACE ... ENGINE とともに使用して、既存のテーブルまたはテーブルスペースの記憶域エンジンを変更することもできません。 これを試行すると、ER_DISABLED_STORAGE_ENGINE エラーが発生します。

disabled_storage_engines では、CREATE INDEX, TRUNCATE TABLE, ANALYZE TABLE, DROP TABLE や DROP TABLESPACE などの既存のテーブルに対する他の DDL ステートメントは制限されません。 これにより、無効なエンジンを使用する既存のテーブルまたはテーブルスペースを、ALTER TABLE ... ENGINE permitted_engine などの方法で許可されたエンジンに移行できるように、スムーズな遷移が可能になります。

default_storage_engine または default_tmp_storage_engine システム変数を無効になっているストレージエンジンに設定できます。 これにより、アプリケーションは誤って動作または失敗する可能性がありますが、無効化されたエンジンを使用するアプリケーションを識別して変更できるように開発環境で有用な手法である可能性があります。

これらのオプションのいずれかを使用してサーバーを起動した場合、disabled_storage_engines は無効になり、効果はありません: --initialize, --initialize-insecure, --skip-grant-tables。

disconnect_on_expired_password

この変数は、期限切れのパスワードを持つクライアントをサーバーが処理する方法を制御します。

期限切れパスワードに関するクライアントとサーバーの対話の設定の詳細については、セクション6.2.16「期限切れパスワードのサーバー処理」を参照してください。

div_precision_increment

この変数は、/ 演算子で実行される除算の結果のスケールを増やす桁数を示します。 デフォルト値は 4 です。 最小値および最大値は、それぞれ 0 および 30 です。 次の例は、デフォルト値を増やした効果を説明したものです。

mysql> SELECT 1/7;
+--------+
| 1/7    |
+--------+
| 0.1429 |
+--------+
mysql> SET div_precision_increment = 12;
mysql> SELECT 1/7;
+----------------+
| 1/7            |
+----------------+
| 0.142857142857 |
+----------------+

dragnet.log_error_filter_rules

log_filter_dragnet エラーログフィルタコンポーネントの操作を制御するフィルタルール。 log_filter_dragnet がインストールされていない場合、dragnet.log_error_filter_rules は使用できません。 log_filter_dragnet がインストールされているが有効になっていない場合、dragnet.log_error_filter_rules への変更は無効です。

デフォルト値の効果は、log_error_verbosity=2 の設定を使用して log_sink_internal フィルタによって実行されるフィルタリングに似ています。

MySQL 8.0.12 の時点では、dragnet.Status ステータス変数を参照して、dragnet.log_error_filter_rules への最新の割当ての結果を判断できます。

MySQL 8.0.12 より前は、実行時に dragnet.log_error_filter_rules への割当てが成功すると、新しい値を確認するノートが生成されます:

mysql> SET GLOBAL dragnet.log_error_filter_rules = 'IF prio <> 0 THEN unset prio.';
Query OK, 0 rows affected, 1 warning (0.00 sec)

mysql> SHOW WARNINGS\G
*************************** 1. row ***************************
  Level: Note
   Code: 4569
Message: filter configuration accepted:
         SET @@GLOBAL.dragnet.log_error_filter_rules=
         'IF prio!=ERROR THEN unset prio.';

SHOW WARNINGS によって表示される値は、ルールセットが正常に解析されて内部形式にコンパイルされた後の 「decompiled」 正規表現を示します。 意味上、この正規の形式は dragnet.log_error_filter_rules に割り当てられた値と同じですが、前述の例に示すように、割り当てられた値と正規の値にはいくつかの違いがある場合があります:

詳細については、セクション5.4.2.4「エラーログフィルタリングのタイプ」,およびセクション5.5.3「エラーログコンポーネント」を参照してください。

end_markers_in_json

オプティマイザ JSON 出力がエンドマーカーを追加するかどうか。 「MySQL 内部: end_markers_in_json システム変数」を参照してください。

eq_range_index_dive_limit

この変数は、オプティマイザが限定する行数を推定するときに、インデックスダイブの使用からインデックス統計の使用に切り換える場合の等価比較条件内の等価範囲の数を指定します。 これは次に示す同等のいずれかの形式を持つ式の評価に適用され、このときオプティマイザは一意でないインデックスを使用して col_name 値を参照します。

col_name IN(val1, ..., valN)
col_name = val1 OR ... OR col_name = valN

どちらの場合も、式に N 個の等価範囲が含まれています。 オプティマイザはインデックスダイブまたはインデックス統計を使用すると行の推定を実行できます。 eq_range_index_dive_limit が 0 より大きい場合、eq_range_index_dive_limit 以上の等価範囲があれば、オプティマイザはインデックスダイブの代わりに既存のインデックス統計を使用します。 したがって、N 個までの等価範囲に対してインデックスダイブの使用を可能にするには、eq_range_index_dive_limit を N + 1 に設定します。 インデックス統計の使用を無効にし、N に関係なく常にインデックスダイブを使用するには、eq_range_index_dive_limit を 0 に設定します。

詳細については、複数値比較の等価範囲の最適化を参照してください。

最適な推定を行うためにテーブルインデックス統計を更新するには、ANALYZE TABLE を使用します。

error_count

メッセージを生成した最後のステートメントから発生したエラーの数。 この変数は読み取り専用です。 セクション13.7.7.17「SHOW ERRORS ステートメント」を参照してください。

event_scheduler

この変数は、イベントスケジューラを有効または無効にし、起動または停止します。 使用可能なステータス値は、ON、OFF および DISABLED で、デフォルトは OFF です。 イベントスケジューラの有効化 OFF は、ステータスを DISABLED に設定する必要があるイベントスケジューラを無効にすることと同じではありません。 この変数とそのイベントスケジューラ操作への影響の詳細は、セクション25.4.2「イベントスケジューラの構成」 を参照してください

explicit_defaults_for_timestamp

このシステム変数は、サーバーがデフォルト値に対して特定の非標準動作を有効にするかどうか、および TIMESTAMP カラムで NULL 値の処理を有効にするかどうかを決定します。 デフォルトでは、explicit_defaults_for_timestamp は有効になっており、非標準動作は無効になっています。 explicit_defaults_for_timestamp を無効にすると、警告が表示されます。

MySQL 8.0.18 では、このシステム変数のセッション値の設定は制限付き操作ではなくなりました。

explicit_defaults_for_timestamp が無効になっている場合、サーバーは非標準動作を有効にし、次のように TIMESTAMP カラムを処理します:

前述の非標準の動作は非推奨です。将来の MySQL リリースで削除される予定です。

explicit_defaults_for_timestamp が有効になっている場合、サーバーは非標準動作を無効にし、次のように TIMESTAMP カラムを処理します:

サーバーの起動時に explicit_defaults_for_timestamp が無効になっている場合、次の警告がエラーログに表示されます:

[Warning] TIMESTAMP with implicit DEFAULT value is deprecated.
Please use --explicit_defaults_for_timestamp server option (see
documentation for more details).

警告に示されているように、非推奨の非標準動作を無効にするには、サーバーの起動時に explicit_defaults_for_timestamp システム変数を有効にします。

追加情報については セクション11.2.5「TIMESTAMP および DATETIME の自動初期化および更新機能」を参照してください。

external_user

クライアントを認証するために使用されるプラグインによって設定された、認証プロセス中に使用される外部ユーザー名。 ネイティブ (組み込み型) の MySQL 認証や、プラグインで値が設定されない場合、この変数は NULL です。 セクション6.2.18「プロキシユーザー」を参照してください。

フラッシュ

ON の場合、各 SQL ステートメントのあとでサーバーはすべての変更をデスクにフラッシュ (同期) します。 通常、MySQL では各 SQL ステートメントの終了後にのみすべての変更内容をディスクに書き込み、ディスクへの同期はオペレーティングシステムが処理します。 セクションB.3.3.3「MySQL が繰り返しクラッシュする場合の対処方法」を参照してください。 --flush オプションで mysqld を起動した場合、この変数は ON に設定されます。

flush_time

これがゼロ以外の値に設定されると、すべてのテーブルは flush_time 秒ごとに閉じられて、リソースが解放され、フラッシュされていないデータがディスクへ同期されます。 このオプションは、リソースが非常に限定されたシステムでのみ使用することを推奨します。

foreign_key_checks

1 (デフォルト) に設定すると、外部キー制約がチェックされます。 0 に設定すると、外部キー制約は無視されますが、いくつかの例外があります。 削除されたテーブルを再作成する場合、テーブル定義がテーブルを参照する外部キー制約に準拠していないと、エラーが返されます。 同様に、外部キー定義の形式が正しくない場合、ALTER TABLE 操作はエラーを返します。 詳細は、セクション13.1.20.5「FOREIGN KEY の制約」を参照してください。

この変数を設定すると、NDB テーブルには InnoDB テーブルと同じ効果があります。 一般的に、通常の操作中はこの設定を有効にしたままにすることで、参照整合性を強制します。 外部キーチェックを無効にすると、親/子関係に必要な順序とは異なる順序で InnoDB テーブルをリロードする場合に役立ちます。 セクション13.1.20.5「FOREIGN KEY の制約」を参照してください。

foreign_key_checks を 0 に設定すると、データ定義ステートメントにも影響します。DROP SCHEMA は、スキーマの外部のテーブルによって参照されている外部キーを持つテーブルをスキーマが含む場合であってもスキーマをドロップし、DROP TABLE は、別のテーブルによって参照されている外部キーを持つテーブルをドロップします。

ft_boolean_syntax

IN BOOLEAN MODE を使用して実行されるブール全文検索によってサポートされる演算子のリスト。 セクション12.10.2「ブール全文検索」を参照してください。

デフォルトの変数値は '+ -><()~*:""&|' です。 値を変更するルールは次のようになります。

ft_max_word_len

MyISAM FULLTEXT インデックスに含めることができる最大の単語の長さ。

ft_min_word_len

MyISAM FULLTEXT インデックスに含めることができる最小の単語の長さ。

ft_query_expansion_limit

WITH QUERY EXPANSION を使用して実行する全文検索で使用する最上位の一致の数。

ft_stopword_file

MyISAM テーブルの全文検索について、ストップワードのリストの読み取り元ファイル。 サーバーは、別のディレクトリを指定する絶対パス名が指定されないかぎり、データディレクトリ内のファイルを検索します。 ファイル内のすべての単語が使用され、コメントは受け付けされません。 デフォルトでは、ストップワードの組み込みリストが使用されます (storage/myisam/ft_static.c ファイルに定義されています)。 この変数を空の文字列 ('') に設定すると、ストップワードフィルタリングが無効になります。 セクション12.10.4「全文ストップワード」も参照してください。

general_log

一般クエリーログを有効にするかどうか。 値が 0 (または OFF) の場合はログを無効にし、1 (または ON) の場合はログを有効にします。 ログ出力先は log_output システム変数によって制御され、この値を NONE にした場合はログが有効になっていてもログエントリは書き込まれません。

general_log_file

一般クエリーログファイルの名前。 デフォルト値は host_name.log ですが、初期値は --general_log_file オプションを使用すると変更できます。

generated_random_password_length

CREATE USER、ALTER USER および SET PASSWORD ステートメントに対して生成されるランダムパスワードで許可される最大文字数。 詳細は、ランダムパスワード生成を参照してください。

group_concat_max_len

GROUP_CONCAT() 関数について許可されるバイト単位の最大の結果の長さ。 デフォルトは 1024 です。

have_compress

zlib 圧縮ライブラリがサーバーで利用できる場合は YES、そうでない場合は NO。 利用できない場合、COMPRESS() および UNCOMPRESS() 関数は使用できません。

have_dynamic_loading

mysqld がプラグインの動的ロードをサポートする場合は YES、そうでない場合は NO。 値が NO の場合、--plugin-load などのオプションを使用してサーバー起動時にプラグインをロードしたり、INSTALL PLUGIN ステートメントを使用して実行時にプラグインをロードしたりすることはできません。

have_geometry

サーバーが空間データ型をサポートする場合は YES、そうでない場合は NO。

have_openssl

この変数は、have_ssl のシノニムです。

have_profiling

ステートメントプロファイリング機能が存在する場合は YES、そうでない場合は NO。 存在する場合、この機能を有効または無効にするかが profiling システム変数によって制御されます。 セクション13.7.7.31「SHOW PROFILES ステートメント」を参照してください。

この変数は非推奨であり、将来の MySQL リリースで削除される予定です。

have_query_cache

クエリーキャッシュは MySQL 8.0.3 で削除されました。have_query_cache は非推奨であり、常に NO の値を持ち、将来の MySQL リリースで削除される予定です。

have_rtree_keys

RTREE インデックスを利用できる場合は YES、そうでない場合は NO。 (これらは MyISAM テーブル内の空間インデックスで使用されます。)

have_ssl

YES (mysqld が SSL 接続をサポートしている場合)、DISABLED(サーバーが SSL サポート付きでコンパイルされているが、適切な connection-encryption オプションで起動されていない場合)。 詳細は、セクション2.9.6「SSL ライブラリサポートの構成」を参照してください。

have_statement_timeout

ステートメントの実行タイムアウト機能が使用可能かどうか (ステートメント実行時オプティマイザヒント を参照)。 この機能で使用されるバックグラウンドスレッドを初期化できなかった場合、値は NO になります。

have_symlink

シンボリックリンクサポートを有効化している場合は YES、そうでない場合はNO。 これは、DATA DIRECTORY および INDEX DIRECTORY テーブルオプションをサポートするために Unix で必要です。 --skip-symbolic-links オプションを指定してサーバーが開始された場合、この値は DISABLED です。

この変数は Windows では意味がありません。

histogram_generation_max_mem_size

ヒストグラム統計の生成に使用可能なメモリーの最大量。 セクション8.9.6「オプティマイザ統計」およびセクション13.7.3.1「ANALYZE TABLE ステートメント」を参照してください。

このシステム変数のセッション値の設定は制限された操作です。 セッションユーザーには、制限付きセッション変数を設定するのに十分な権限が必要です。 セクション5.1.9.1「システム変数権限」を参照してください。

host_cache_size

MySQL サーバーは、クライアントホスト名および IP アドレス情報を含むインメモリーホストキャッシュを保持し、ドメインネームシステム (DNS) のルックアップを回避するために使用されます。セクション5.1.12.3「DNS ルックアップとホストキャッシュ」 を参照してください。

host_cache_size 変数は、ホストキャッシュのサイズと、キャッシュの内容を公開するパフォーマンススキーマ host_cache テーブルのサイズを制御します。 host_cache_size を設定すると、次の効果があります:

デフォルト値は 128 に自動サイズ設定され、500 までの max_connections の値には 1 が加算され、max_connections 値の 500 を超えるすべての増分には 1 が加算され、制限は 2000 に制限されます。

--skip-host-cache オプションの使用は、host_cache_size システム変数を 0 に設定するのと似ていますが、host_cache_size は、サーバーの起動時だけでなく、実行時にホストキャッシュのサイズ変更、有効化、および無効化にも使用できるため、より柔軟です。 --skip-host-cache を使用してサーバーを起動しても、host_cache_size の値に対する実行時の変更は妨げられませんが、このような変更は効果がなく、host_cache_size が 0 より大きい値に設定されていてもキャッシュは再度有効になりません。

hostname

サーバーは起動時に、この変数をサーバーホスト名に設定します。 RFC 1034 によると、MySQL 8.0.17 での最大長は 255 文字で、その前は 60 文字です。

identity

この変数は last_insert_id 変数のシノニムです。 これはほかのデータベースシステムとの互換性のために存在します。 この値は SELECT @@identity で読み取ることができ、SET identity で設定できます。

init_connect

接続する各クライアントに対してサーバーによって実行される文字列。 文字列は 1 つ以上の SQL ステートメントで構成され、セミコロン文字で区切られます。

CONNECTION_ADMIN 権限 (または非推奨の SUPER 権限) を持つユーザーの場合、init_connect のコンテンツは実行されません。 これを行うのは、init_connect の値が誤っていても、すべてのクライアントの接続を妨げないようにするためです。 たとえば、値に含まれているステートメントが構文エラーを含むため、クライアント接続が失敗することがあります。 CONNECTION_ADMIN または SUPER 権限を持つユーザーに対して init_connect を実行しないと、接続をオープンして init_connect 値を修正できます。

パスワードが期限切れのクライアントユーザーの場合、init_connect の実行はスキップされます。 これは、このようなユーザーは任意のステートメントを実行できないため、init_connect の実行が失敗し、クライアントが接続できなくなるためです。 init_connect の実行をスキップすると、ユーザーは接続してパスワードを変更できます。

サーバーは、init_connect の値のステートメントによって生成されたすべての結果セットを破棄します。

information_schema_stats_expiry

一部の INFORMATION_SCHEMA テーブルには、テーブル統計を提供するカラムが含まれています:

STATISTICS.CARDINALITY
TABLES.AUTO_INCREMENT
TABLES.AVG_ROW_LENGTH
TABLES.CHECKSUM
TABLES.CHECK_TIME
TABLES.CREATE_TIME
TABLES.DATA_FREE
TABLES.DATA_LENGTH
TABLES.INDEX_LENGTH
TABLES.MAX_DATA_LENGTH
TABLES.TABLE_ROWS
TABLES.UPDATE_TIME

これらのカラムは、動的テーブルメタデータ、つまりテーブルの内容の変更に応じて変更される情報を表します。

デフォルトでは、MySQL は、カラムのクエリー時に mysql.index_stats および mysql.table_stats ディクショナリテーブルからこれらのカラムのキャッシュされた値を取得します。これは、ストレージエンジンから統計を直接取得するよりも効率的です。 キャッシュされた統計が使用できないか、期限切れになっている場合、MySQL はストレージエンジンから最新の統計を取得し、mysql.index_stats および mysql.table_stats ディクショナリテーブルにキャッシュします。 後続のクエリーでは、キャッシュされた統計が期限切れになるまで、キャッシュされた統計が取得されます。

information_schema_stats_expiry セッション変数は、キャッシュされた統計が期限切れになるまでの期間を定義します。 デフォルトは 86400 秒 (24 時間) ですが、期間は 1 年まで延長できます。

特定のテーブルのキャッシュされた値をいつでも更新するには、ANALYZE TABLE を使用します。

常に最新の統計をストレージエンジンから直接取得し、キャッシュされた値をバイパスするには、information_schema_stats_expiry を 0 に設定します。

次の場合、統計カラムのクエリーでは、mysql.index_stats および mysql.table_stats ディクショナリテーブルの統計は格納または更新されません:

information_schema_stats_expiry はセッション変数であり、各クライアントセッションで独自の有効期限値を定義できます。 ストレージエンジンから取得され、あるセッションによってキャッシュされた統計は、ほかのセッションで使用できます。

関連情報については、セクション8.2.3「INFORMATION_SCHEMA クエリーの最適化」を参照してください。

init_file

指定した場合、この変数は、起動プロセス中に読み取られて実行される SQL ステートメントを含むファイルに名前を付けます。 MySQL 8.0.18 より前では、各ステートメントは単一行に記述する必要があり、コメントを含めることはできません。 MySQL 8.0.18 の時点では、ファイル内のステートメントの許容形式は、次の構成をサポートするように拡張されています:

サーバーが --initialize または --initialize-insecure オプションを使用して起動された場合、それはブートスタップモードで動作し、ファイルで許可されるステートメントを制限する一部の機能は使用できません。 これには、アカウント管理 (CREATE USER、GRANT など)、レプリケーションおよびグローバルトランザクション識別子に関連するステートメントが含まれます。 セクション17.1.3「グローバルトランザクション識別子を使用したレプリケーション」を参照してください。

MySQL 8.0.17 では、サーバーの起動時に作成されたスレッドは、データディクショナリの作成、アップグレード手順の実行、システムテーブルの作成などのタスクに使用されます。 安定した予測可能な環境を確保するために、これらのスレッドは、sql_mode, character_set_server, collation_server, completion_type, explicit_defaults_for_timestamp や default_table_encryption などの一部のシステム変数のサーバー組込みデフォルトを使用して実行されます。

これらのスレッドは、サーバーの起動時に init_file で指定されたファイル内のステートメントを実行するためにも使用されるため、このようなステートメントは、これらのシステム変数のサーバーに組み込まれたデフォルト値で実行されます。

innodb_xxx

InnoDB システム変数は、セクション15.14「InnoDB の起動オプションおよびシステム変数」にリストされています。 これらの変数は、InnoDB テーブルの記憶域、メモリー使用および I/O パターンの多くの側面を制御し、InnoDB がデフォルトの記憶域エンジンであることが特に重要です。

insert_id

AUTO_INCREMENT 値を挿入するときに、後に続く INSERT または ALTER TABLE ステートメントによって使用される値。 これは主にバイナリログと一緒に使用されます。

interactive_timeout

サーバーが対話型の接続で、対話型の接続を閉じる前にアクティビティーを待機する秒数。 対話型クライアントは、mysql_real_connect() で CLIENT_INTERACTIVE オプションを使用するクライアントと定義されます。 wait_timeoutも参照してください。

internal_tmp_disk_storage_engine

MySQL 8.0.16 より前は、この変数によって、ディスク上の内部一時テーブルに使用されるストレージエンジンが決まります (オンディスク内部一時テーブルのストレージエンジン を参照)。 許可される値は、MYISAM および INNODB (デフォルト) です。

internal_tmp_mem_storage_engine

インメモリー内部一時テーブルのストレージエンジン (セクション8.4.4「MySQL での内部一時テーブルの使用」 を参照)。 許可される値は、TempTable (デフォルト) および MEMORY です。

optimizer は、インメモリー内部一時テーブル用に internal_tmp_mem_storage_engine によって定義されたストレージエンジンを使用します。

join_buffer_size

単純インデックススキャン、範囲インデックススキャン、およびインデックスを使用しないため完全テーブルスキャンを実行する結合について、使用されるバッファーの最小サイズ。 通常の場合、高速な結合を得るための最適な方法は、インデックスを追加することです。 インデックスを追加できない場合、より高速な完全結合を得るために、join_buffer_size の値を大きくします。 2 つのテーブル間の完全結合 1 つに対して 1 つの結合バッファーが割り当てられます。 インデックスが使用されない複数テーブル間の複雑な結合については、複数の結合バッファーが必要になることもあります。

ブロックネストループアルゴリズムまたはバッチキーアクセスアルゴリズムを使用しないかぎり、一致する各行を保持するために必要な大きさを超えるバッファを設定することはできず、すべての結合で少なくとも最小サイズが割り当てられるため、この変数をグローバルに大きな値に設定する際は注意が必要です。 グローバル設定を小さく保ち、大きな結合を実行しているセッションでのみセッション設定を大きな値に変更するか、SET_VAR オプティマイザヒントを使用してクエリーごとに設定を変更することをお薦めします (セクション8.9.3「オプティマイザヒント」 を参照)。 メモリーを使用するほとんどのクエリーによって必要なサイズよりもグローバルサイズを大きくすると、メモリー割り当て時間が原因でパフォーマンスが著しく低下することがあります。

Block Nested-Loop を使用すると、最初のテーブルのすべての行から必要なすべてのカラムが結合バッファに格納される時点まで、大きな結合バッファが有効になります。 これはクエリーによって異なります。最適なサイズは、最初のテーブルのすべての行を保持するよりも小さくなる場合があります。

バッチ化されたキーアクセスを使用する場合、join_buffer_size の値によって、ストレージエンジンへのリクエストごとにキーのバッチの大きさが定義されます。 バッファが大きいほど、結合操作の右側のテーブルへの順次アクセスが多くなり、パフォーマンスが大幅に向上する可能性があります。

デフォルトは 256KB です。 join_buffer_size で許可される最大の設定値は 4G バイト −1 です。 64 ビットプラットフォームの場合は大きい値が許可されます (64 ビットの Windows の場合は例外で、大きい値は 4G バイト − 1 に切り捨てられて警告が出ます)。

結合バッファリングについての追加情報は、セクション8.2.1.7「Nested Loop 結合アルゴリズム」を参照してください。 バッチキーアクセスについては、セクション8.2.1.12「Block Nested Loop 結合と Batched Key Access 結合」を参照してください。

keep_files_on_create

MyISAM テーブルが DATA DIRECTORY オプションなしで作成される場合、.MYD ファイルがデータベースディレクトリ内に作成されます。 デフォルトでは、MyISAM が既存の .MYD ファイルを検出した場合、そのファイルを上書きします。 INDEX DIRECTORY オプションを指定せずに作成されたテーブルについて、.MYI ファイルに同じことが当てはまります。 この動作を抑制するには、keep_files_on_create 変数を ON (1) に設定します。この場合、MyISAM は既存のファイルを上書きせず、かわりにエラーを返します。 デフォルト値は OFF (0) です。

MyISAM テーブルが DATA DIRECTORY または INDEX DIRECTORY オプションを使用して作成され、既存の .MYD または .MYI ファイルが見つかった場合、MyISAM は常にエラーを返します。 指定したディレクトリ内のファイルは上書きされません。

key_buffer_size

MyISAM テーブルのインデックスブロックはバッファリングされ、すべてのスレッドで共有されます。key_buffer_size は、インデックスブロックに使用されるバッファーのサイズです。 キーバッファーはキーキャッシュとしても知られています。

32 ビットプラットフォームでは、key_buffer_size に許可される最大の設定値は 4G バイト − 1 です。 64 ビットプラットフォームでは、さらに大きい値が許可されます。 実質的な最大サイズは、使用可能な物理 RAM や、オペレーティングシステムまたはハードウェアプラットフォームによって課されるプロセスごとの RAM 制限によって、もっと小さいことがあります。 この変数の値は、リクエストされるメモリーの量を示します。 サーバーは内部的に、この量までのできるだけ多くのメモリーを割り当てますが、実際の割り当てがもっと少なくなることもあります。

値を増やすことで、すべての読み取りおよび複数の書き込みのインデックス処理を改善できます。システムの主な機能が MyISAM ストレージエンジンを使用して MySQL を実行する場合、マシンの合計メモリーの 25% がこの変数の許容可能な値です。 ただし、値を大きくし過ぎると (マシンの合計メモリーの 50% 超)、システムのページングが始まってきわめて低速になることがあります。 これは MySQL がデータ読み取りのためのファイルシステムキャッシュの実行をオペレーティングシステムに依存しているためで、ファイルシステムキャッシュのためにいくらかの空きを残しておく必要があります。 また、MyISAM に追加して使用するほかのストレージエンジンのメモリー要件も考慮します。

多くの行の同時書き込みなどスピードを高めるには、LOCK TABLES を使用します。 セクション8.2.5.1「INSERT ステートメントの最適化」を参照してください。

キーバッファーのパフォーマンスを確認するために、SHOW STATUS ステートメントを発行し、Key_read_requests、Key_reads、Key_write_requests、および Key_writes のステータス変数を調べることができます。 (セクション13.7.7「SHOW ステートメント」を参照してください。) Key_reads/Key_read_requests の比率は通常は 0.01 より小さくなります。 操作がほとんど更新と削除だけの場合は Key_writes/Key_write_requests の比率は 1 に近くなりますが、同時に多くの行に影響を与える更新を行う場合や、DELAY_KEY_WRITE テーブルオプションを使用する場合はもっと小さくなることがあります。

使用中のキーバッファーの部分は、key_buffer_size に加えて、Key_blocks_unused ステータス変数と、key_cache_block_size システム変数から利用可能なバッファーブロックサイズを使用して決定できます。

1 - ((Key_blocks_unused * key_cache_block_size) / key_buffer_size)

キーバッファー内の一部のスペースは、管理構造の内部で割り当てられるため、この値は概算です。 これらの構造についてのオーバーヘッドの量に影響する要素には、ブロックサイズおよびポインタサイズがあります。 ブロックサイズが増加すると、オーバーヘッドで失われるキーバッファーのパーセントが減少する傾向にあります。 ブロックが大きくなると、読み取り操作の数が少なくなりますが (読み取りあたりで取得されるキーが増えるため)、検査されないキーの読み取りが逆に増加します (ブロック内の一部のキーがクエリーに関連していない場合)。

MyISAM の複数キーキャッシュを作成できます。 グループとしてではなく個別の各キャッシュに対して 4G バイトのサイズ制限が適用されます。 セクション8.10.2「MyISAM キーキャッシュ」を参照してください。

key_cache_age_threshold

この値は、キーキャッシュのホットサブリストからウォームサブリストへのバッファーの格下げを制御します。 値が低いと格下げが早く行われます。 最小値は 100 です。 デフォルト値は 300 です。 セクション8.10.2「MyISAM キーキャッシュ」を参照してください。

key_cache_block_size

キーキャッシュ内のバイト単位のブロックのサイズ。 デフォルト値は 1024 です。 セクション8.10.2「MyISAM キーキャッシュ」を参照してください。

key_cache_division_limit

キーキャッシュバッファーリストのホットサブリストとウォームサブリストの間の分割点。 値は、ウォームサブリスト用に使用するバッファーリストのパーセントです。 許可される値の範囲は 1 から 100 です。 デフォルト値は 100 です。 セクション8.10.2「MyISAM キーキャッシュ」を参照してください。

large_files_support

大きなファイルをサポートするオプションで mysqld をコンパイルしているかどうか。

large_pages

大規模ページサポートが (--large-pages オプションで) 有効になっているかどうか。 セクション8.12.3.2「ラージページのサポートの有効化」を参照してください。

large_page_size

大規模ページサポートが有効化されている場合、これはメモリーページのサイズを示します。 ラージメモリーページは Linux でのみサポートされます。他のプラットフォームでは、この変数の値は常に 0 です。 セクション8.12.3.2「ラージページのサポートの有効化」を参照してください。

last_insert_id

LAST_INSERT_ID() から返される値。 これは、テーブルを更新するステートメント内で LAST_INSERT_ID() を使用するときにバイナリログ内に格納されます。 この変数を設定しても、mysql_insert_id() C API 関数によって返される値は更新されません。

lc_messages

エラーメッセージに使用するロケール。 デフォルトは en_US です。 サーバーは引数を言語名に変換し、これを lc_messages_dir の値と組み合わせてエラーメッセージファイルの場所を生成します。 セクション10.12「エラーメッセージ言語の設定」を参照してください。

lc_messages_dir

エラーメッセージが配置されているディレクトリ。 サーバーはこの値を lc_messages の値と一緒に使用して、エラーメッセージファイルの場所を生成します。 セクション10.12「エラーメッセージ言語の設定」を参照してください。

lc_time_names

この変数は、日および月の名前と略語を表示するために使用する言語を制御するロケールを指定します。 この変数は DATE_FORMAT()、DAYNAME()、および MONTHNAME() 関数の出力に影響を与えます。 ロケール名は、'ja_JP' や 'pt_BR' などの POSIX 規格の値です。 システムのロケール設定に関係なく、デフォルト値は 'en_US' です。 詳細については、セクション10.16「MySQL Server のロケールサポート」を参照してください。

license

サーバーが持つライセンスのタイプ。

local_infile

この変数は、LOAD DATA ステートメントのサーバー側 LOCAL 機能を制御します。 local_infile の設定に応じて、サーバーはクライアント側で LOCAL が有効になっているクライアントによるローカルデータロードを拒否または許可します。

サーバーが LOAD DATA LOCAL ステートメントを明示的に拒否または許可するようにするには (構築時または実行時にクライアントプログラムおよびライブラリがどのように構成されているかに関係なく)、それぞれ local_infile を無効または有効にして mysqld を起動します。local_infile は実行時に設定することもできます。 詳細は、セクション6.1.6「LOAD DATA LOCAL のセキュリティー上の考慮事項」を参照してください。

lock_wait_timeout

この変数は、メタデータロックを取得するための試行のタイムアウトを秒単位で指定します。 許可される値の範囲は 1 から 31536000 (1 年) です。 デフォルトは 31536000 です。

このタイムアウトは、メタデータロックを使用するすべてのステートメントに適用されます。 これらには、テーブル、ビュー、ストアドプロシージャー、ストアドファンクションの DML 操作および DDL 操作のほかに、LOCK TABLES、FLUSH TABLES WITH READ LOCK、および HANDLER ステートメントが含まれます。

このタイムアウトは、GRANT または REVOKE ステートメントやテーブルロギングステートメントによって変更される付与テーブルなど、mysql データベース内のシステムテーブルへの暗黙的なアクセスには適用されません。 タイムアウトは、SELECT や UPDATE などによって直接アクセスされるシステムテーブルに適用されます。

タイムアウト値は、メタデータロック試行ごとに別々に適用されます。 ある特定のステートメントが複数のロックを必要とする場合もあるため、タイムアウトエラーを報告する前に、ステートメントが lock_wait_timeout 値よりも長くブロックする可能性もあります。 ロックタイムアウトが発生すると、ER_LOCK_WAIT_TIMEOUT が報告されます。

lock_wait_timeout では、LOCK INSTANCE FOR BACKUP ステートメントがロックを放棄するまで待機する時間も定義されます。

locked_in_memory

mysqld が --memlock によってメモリー内でロックされたかどうか。

log_error

デフォルトのエラーログの保存先。 宛先がコンソールの場合、値は stderr です。 それ以外の場合、宛先はファイルで、log_error 値はファイル名です。 セクション5.4.2「エラーログ」 を参照してください。

log_error_services

エラーロギングを有効にするコンポーネント。 変数には、0、1 または多数の要素を含むリストを含めることができます。 後者の場合、要素はセミコロンまたは (MySQL 8.0.12 の時点で) カンマで区切り、オプションでスペースを続けることができます。 指定された設定にセミコロンとカンマの両方のセパレータを使用することはできません。 サーバーはリストされた順序でコンポーネントを実行するため、コンポーネントの順序は重要です。 log_error_services 値に指定されたロード可能な (組込みではない) コンポーネントは、最初に INSTALL COMPONENT とともにインストールする必要があります。 詳細は、セクション5.4.2.1「エラーログ構成」を参照してください。

log_error_suppression_list

log_error_suppression_list システム変数は、エラーログを対象としたイベントに適用され、WARNING または INFORMATION の優先度で発生した場合に抑制するイベントを指定します。 たとえば、特定のタイプの警告が頻繁に発生するが関心がないためにエラーログで望ましくない「「ノイズ」」とみなされる場合は、抑止できます。 この変数は、デフォルトで有効になっている log_filter_internal エラーログフィルタコンポーネントによって実行されるフィルタリングに影響します (セクション5.5.3「エラーログコンポーネント」 を参照)。 log_filter_internal が無効になっている場合、log_error_suppression_list は影響を与えません。

log_error_suppression_list 値には、抑制しない場合は空の文字列、抑制するエラーコードを示すカンマ区切り値のリストを指定できます。 エラーコードはシンボリックまたは数値形式で指定できます。 数値コードは、MY- 接頭辞の有無にかかわらず指定できます。 数値部分の先頭のゼロは重要ではありません。 許可されているコード形式の例:

ER_SERVER_SHUTDOWN_COMPLETE
MY-000031
000031
MY-31
31

読みやすく移植性を高めるために、数値よりもシンボリック値をお薦めします。 許可されるエラー記号およびエラー番号の詳細は、MySQL 8.0 Error Message Reference を参照してください。

log_error_suppression_list の効果は、log_error_verbosity の効果と結合されます。 追加情報については セクション5.4.2.5「優先度ベースのエラーログのフィルタリング (log_filter_internal)」を参照してください。

log_error_verbosity

log_error_verbosity システム変数は、エラーログを対象としたイベントを処理するための冗長性を指定します。 この変数は、デフォルトで有効になっている log_filter_internal エラーログフィルタコンポーネントによって実行されるフィルタリングに影響します (セクション5.5.3「エラーログコンポーネント」 を参照)。 log_filter_internal が無効になっている場合、log_error_verbosity は影響を与えません。

エラーログを対象としたイベントの優先度は、ERROR、WARNING または INFORMATION です。log_error_verbosity は、次のテーブルに示すように、ログに書き込まれるメッセージに対して許可する優先度に基づいて冗長性を制御します。

SYSTEM の優先度もあります。 log_error_verbosity の値に関係なく、エラー以外の状況に関するシステムメッセージがエラーログに出力されます。 これらのメッセージには、起動メッセージと停止メッセージ、および設定に対する重要な変更が含まれます。

log_error_verbosity の効果は、log_error_suppression_list の効果と結合されます。 追加情報については セクション5.4.2.5「優先度ベースのエラーログのフィルタリング (log_filter_internal)」を参照してください。

log_output

一般クエリーログおよびスロークエリーログ出力の宛先。 値は、TABLE、FILE および NONE から選択されたカンマ区切りの単語のリストです。 TABLE は、mysql システムスキーマ内の general_log および slow_log テーブルへのロギングを選択します。 FILE は、ログファイルへのロギングを選択します。 NONE はロギングを無効にします。 値に NONE が存在する場合は、存在する他の単語よりも優先されます。 TABLE と FILE の両方を指定して、両方のログ出力先を選択できます。

この変数は、ログ出力先を選択しますが、ログ出力は有効にしません。 これを行うには、general_log および slow_query_log システム変数を有効にします。 FILE ロギングの場合、general_log_file および slow_query_log_file システム変数によってログファイルの場所が決まります。 詳細については、セクション5.4.1「一般クエリーログおよびスロークエリーログの出力先の選択」を参照してください。

log_queries_not_using_indexes

スロークエリーログを有効にしてこの変数を有効にすると、すべての行を取得すると予想されるクエリーがログに記録されます。 セクション5.4.5「スロークエリーログ」を参照してください。 このオプションは、インデックスが使用されないことを必ずしも意味するわけではありません。 たとえば、フルインデックススキャンを使用するクエリーはインデックスを使用しますが、インデックスは行数を制限しないため、クエリーはログに記録されます。

log_raw

log_raw システム変数は、最初は --log-raw オプションの値に設定されます。 詳細は、そのオプションの説明を参照してください。 システム変数を実行時に設定して、パスワードマスキング動作を変更することもできます。

log_slow_admin_statements

スロークエリーログに書き込まれるステートメントにスロー管理ステートメントを含めます。 管理ステートメントには、ALTER TABLE、ANALYZE TABLE、CHECK TABLE、CREATE INDEX、DROP INDEX、OPTIMIZE TABLE、および REPAIR TABLE が含まれます。

log_slow_extra

スロークエリーログが有効で、出力先に FILE が含まれている場合、サーバーはスローステートメントに関する情報を提供する追加のフィールドをログファイル行に書き込みます。 セクション5.4.5「スロークエリーログ」を参照してください。 TABLE 出力は影響を受けません。

log_syslog

MySQL 8.0 より前では、この変数はシステムログ (Windows の場合はイベントログ、Unix および Unix に似たシステムの場合は syslog) にエラーロギングを実行するかどうかを制御していました。

MySQL 8.0 では、log_sink_syseventlog ログコンポーネントによってシステムログへのエラーロギングが実装されるため (セクション5.4.2.8「システムログへのエラーロギング」 を参照)、log_error_services システム変数にこのタイプのロギングを追加することで有効にできます。log_syslog が削除されます。 (MySQL 8.0.13 より前は、log_syslog は存在していましたが、非推奨であり、効果はありません。)

log_syslog_facility

この変数は MySQL 8.0.13 で削除され、syseventlog.facility に置き換えられました。

log_syslog_include_pid

この変数は MySQL 8.0.13 で削除され、syseventlog.include_pid に置き換えられました。

log_syslog_tag

この変数は MySQL 8.0.13 で削除され、syseventlog.tag に置き換えられました。

log_timestamps

この変数は、エラーログに書き込まれるメッセージのタイムスタンプ、およびファイルに書き込まれる一般的なクエリーログメッセージとスロークエリーログメッセージのタイムゾーンを制御します。 一般クエリーログおよびテーブル (mysql.general_log、mysql.slow_log) に書き込まれるスロークエリーログメッセージのタイムゾーンには影響しません。 これらのテーブルから取得された行は、CONVERT_TZ() を使用するか、セッションの time_zone システム変数を設定することで、ローカルシステムのタイムゾーンから任意のタイムゾーンに変換できます。

許可される log_timestamps 値は、UTC (デフォルト) および SYSTEM (ローカルシステムのタイムゾーン) です。

タイムスタンプは ISO 8601 / RFC 3339 形式を使用して書き込まれます: YYYY-MM-DDThh:mm:ss.uuuuuu に Zulu 時間 (UTC) または±hh:mm (UTC からのオフセット) を示す Z の末尾の値を加えたもの。

log_throttle_queries_not_using_indexes

log_queries_not_using_indexes が有効な場合、log_throttle_queries_not_using_indexes 変数は、スロークエリーログに書き込み可能な分あたりのクエリー数を制限します。 値 0 (デフォルト) は「制限なし」を意味します。 詳細は、セクション5.4.5「スロークエリーログ」を参照してください。

long_query_time

クエリーの時間がこの秒数よりかかると、サーバーは Slow_queries ステータス変数を増やします。 スロークエリーログが有効な場合、クエリーはスロークエリーログファイルに記録されます。 この値は CPU 時間でなくリアルタイムで測定されるため、負荷の軽いシステムでしきい値を下回るクエリーが、負荷の重いシステムではしきい値を超える場合もあります。 long_query_time の最小値およびデフォルト値は、それぞれ 0 および 10 です。 値はマイクロ秒の精度まで指定できます。 セクション5.4.5「スロークエリーログ」を参照してください。

この変数の値を小さくすると、長時間実行とみなされるステートメントが増えるため、スロークエリーログに必要な領域が増えます。 非常に小さい値 (1 秒未満) の場合、ログは非常に大きくなることがあります。 長時間実行とみなされるステートメントの数を増やすと、特にグループレプリケーションが有効になっている場合に、MySQL Enterprise Monitor の「「長時間実行プロセスの数が多すぎます」」アラートに対して誤検出が発生する可能性もあります。 これらの理由から、非常に小さい値はテスト環境でのみ使用するか、本番環境では短期間のみ使用する必要があります。

low_priority_updates

1 に設定された場合、すべての INSERT、UPDATE、DELETE、および LOCK TABLE WRITE ステートメントは、影響を受けるテーブルでの保留中の SELECT または LOCK TABLE READ がなくなるまで待機します。 {INSERT | REPLACE | DELETE | UPDATE} LOW_PRIORITY ... を使用して同じ効果を得て、クエリーの優先度を下げることができます。 この変数は、テーブルレベルのロック (MyISAM、MEMORY、MERGE など) のみを使用するストレージエンジンにのみ影響します。 セクション8.11.2「テーブルロックの問題」を参照してください。

lower_case_file_system

この変数は、データディレクトリが配置されているファイルシステムでのファイル名の大文字小文字の区別を示します。 OFF では、ファイル名は大/小文字が区別され、ON では大/小文字が区別されません。 この変数は、ファイルシステム属性を反映するため読み取り専用で、変数を設定してもファイルシステムに影響しません。

lower_case_table_names

0 に設定すると、テーブル名は指定したとおりに格納され、比較では大/小文字が区別されます。 1 に設定すると、テーブル名はディスクに小文字で格納され、比較では大文字と小文字は区別されません。 2 に設定されると、テーブル名は指定したとおりに格納されますが、小文字で比較されます。 このオプションはデータベース名やテーブルエイリアスにも適用されます。 追加の詳細については、セクション9.2.3「識別子の大文字と小文字の区別」を参照してください。

Windows では、デフォルト値は 1 です。 macOS では、デフォルト値は 2 です。 Linux では、値 2 はサポートされていません。かわりに、サーバーは値を強制的に 0 にします。

データディレクトリが大/小文字を区別しないファイルシステム (Windows や macOS など) に存在するシステムで MySQL を実行している場合は、lower_case_table_names を 0 に設定しないでください。 これはサポートされていない組合せであり、間違った tbl_name 文字ケースで INSERT INTO ... SELECT ... FROM tbl_name 操作を実行するとハング状態になる可能性があります。 MyISAM では、異なる大文字と小文字を使用してテーブル名にアクセスすると、インデックスが破損する可能性があります。

大/小文字を区別しないファイルシステムで --lower_case_table_names=0 を使用してサーバーを起動しようとすると、エラーメッセージが出力され、サーバーが終了します。

InnoDB テーブルを使用する場合、名前を強制的に小文字に変換するために、すべてのプラットフォームでこの値を 1 に設定します。

この変数の設定は、大文字と小文字の区別に関してレプリケーションフィルタリングオプションの動作に影響します。 詳細は、セクション17.2.5「サーバーがレプリケーションフィルタリングルールをどのように評価するか」を参照してください。

サーバーの初期化時に使用された設定とは異なる lower_case_table_names 設定でサーバーを起動することは禁止されています。 様々なデータディクショナリテーブルのフィールドで使用される照合は、サーバーの初期化時に定義された設定によって決定され、異なる設定でサーバーを再起動すると、識別子の順序付けおよび比較方法に矛盾が生じるため、制限が必要です。

したがって、サーバーを初期化する前に、lower_case_table_names を目的の設定に構成する必要があります。 ほとんどの場合、MySQL サーバーを初めて起動する前に、MySQL オプションファイルで lower_case_table_names を構成する必要があります。 ただし、Debian および Ubuntu での APT インストールの場合、サーバーは初期化され、事前にオプションファイルで設定を構成する機会はありません。 そのため、lower_case_table_names を有効にするには、APT を使用して MySQL をインストールする前に debconf-set-selection ユーティリティを使用する必要があります。 これを行うには、APT を使用して MySQL をインストールする前に、次のコマンドを実行します:

shell> sudo debconf-set-selections <<< "mysql-server mysql-server/lowercase-table-names select Enabled

mandatory_roles

サーバーが必須として扱う必要があるロール。 実際には、これらのロールはすべてのユーザーに自動的に付与されますが、mandatory_roles を設定しても実際にはユーザーアカウントは変更されず、付与されたロールは mysql.role_edges システムテーブルに表示されません。

変数値は、ロール名のカンマ区切りリストです。 例:

SET PERSIST mandatory_roles = '`role1`@`%`,`role2`,role3,role4@localhost';

mandatory_roles のランタイム値を設定するには、グローバルシステム変数のランタイム値を設定するために通常必要な SYSTEM_VARIABLES_ADMIN 権限 (または非推奨の SUPER 権限) に加えて、ROLE_ADMIN 権限が必要です。

ロール名は、user_name@host_name 形式のユーザー部分とホスト部分で構成されます。 ホスト部分を省略すると、デフォルトで % に設定されます。 追加情報については セクション6.2.5「ロール名の指定」を参照してください。

mandatory_roles 値は文字列であるため、引用符で囲まれている場合は、引用符で囲まれた文字列内での引用に許可された方法でユーザー名とホスト名を記述する必要があります。

mandatory_roles の値で指定されたロールは、REVOKE で取り消すことも、DROP ROLE または DROP USER で削除することもできません。

セッションがデフォルトでシステムセッションにならないようにするには、SYSTEM_USER 権限を持つロールを mandatory_roles システム変数の値にリストできません:

明示的に付与されたロールと同様に、必須ロールはアクティブ化されるまで有効になりません (ロールのアクティブ化 を参照)。 ログイン時に、activate_all_roles_on_login システム変数が有効になっている場合は付与されているすべてのロールに対してロールのアクティブ化が行われ、それ以外の場合はデフォルトロールとして設定されているロールに対してロールのアクティブ化が行われます。 実行時に、SET ROLE によってロールがアクティブ化されます。

mandatory_roles に割り当てられたときに存在しないが、後で作成されるロールでは、特別な処理を必須とみなす必要がある場合があります。 詳細は、必須ロールの定義を参照してください。

SHOW GRANTS では、セクション13.7.7.21「SHOW GRANTS ステートメント」 で説明されているルールに従って必須ロールが表示されます。

max_allowed_packet

1 つのパケット、生成された文字列または中間文字列、または mysql_stmt_send_long_data() C API 関数によって送信されたすべてのパラメータの最大サイズ。 デフォルトは 64M バイトです。

パケットメッセージバッファーは net_buffer_length バイトに初期化されますが、必要に応じて max_allowed_packet バイトまで大きくできます。 この値はデフォルトでは小さいため、大きい (正しくない可能性がある) パケットをキャッチできません。

大きい BLOB カラムまたは長い文字列を使用している場合、この値を大きくする必要があります。 使用する最大の BLOB と同じ大きさにしてください。 max_allowed_packet のプロトコル制限は 1G バイトです。 値は 1024 の倍数にします。倍数でない場合、もっとも近い倍数に切り下げられます。

max_allowed_packet 変数の値を変更することによってメッセージバッファーサイズを変更するとき、クライアントプログラムでそれが可能である場合は、クライアント側のバッファーサイズも変更します。 クライアントライブラリに組み込まれるデフォルトの max_allowed_packet 値は 1G バイトですが、個々のクライアントプログラムはこれをオーバーライドできます。 たとえば、mysql および mysqldump のデフォルトは、それぞれ 16M バイトおよび 24M バイトです。 また、コマンド行またはオプションファイル内で max_allowed_packet を設定することによって、クライアント側の値を変更することもできます。

この変数のセッションの値は、読み取り専用です。 クライアントは、セッション値と同じバイト数まで受信できます。 ただし、サーバーは現在のグローバル max_allowed_packet 値を超えるバイト数をクライアントに送信しません。 (クライアントの接続後にグローバル値が変更された場合、グローバル値はセッション値より小さくなる可能性があります。)

max_connect_errors

正常に接続されずにホストからの max_connect_errors の連続した接続リクエストが中断されると、サーバーはそのホストをそれ以降の接続からブロックします。 前回の接続が中断された後、max_connect_errors の試行回数より少ない時間内にホストからの接続が正常に確立された場合、ホストのエラー数はゼロにクリアされます。 ブロックされたホストのブロックを解除するには、ホストキャッシュをフラッシュします。ホストキャッシュのフラッシュ を参照してください。

max_connections

許可される最大のクライアントの同時接続数。 詳細は、セクション5.1.12.1「接続インタフェース」を参照してください。

max_delayed_threads

このシステム変数は非推奨です (DELAYED の挿入はサポートされていないため)。将来のリリースで削除される予定です。

max_digest_length

正規化されたステートメントダイジェストの計算用にセッションごとに予約されているメモリーの最大バイト数。 ダイジェスト計算中にその量の領域が使用されると、切捨てが発生: 解析されたステートメントからのそれ以上のトークンは収集されず、ダイジェスト値になりません。 解析されたトークンのバイト数が同じ正規化されたステートメントダイジェストを生成し、比較された場合、またはダイジェスト統計のために集計された場合にのみ、ステートメントが同じであるとみなされます。

max_digest_length 値を小さくするとメモリー使用量は減少しますが、末尾のみが異なる場合は、より多くのステートメントのダイジェスト値が区別できなくなります。 この値を大きくすると、より長いステートメントを区別できますが、特に多数の同時セッションを含むワークロード (サーバーはセッションごとに max_digest_length バイトを割り当てます) では、メモリー使用量が増加します。

パーサーは、このシステム変数を、計算する正規化されたステートメントダイジェストの最大長の制限として使用します。 パフォーマンススキーマは、ステートメントダイジェストを追跡する場合、格納するダイジェストの最大長の制限として performance_schema_max_digest_length. システム変数を使用してダイジェスト値のコピーを作成します。 したがって、performance_schema_max_digest_length が max_digest_length より小さい場合、パフォーマンススキーマに格納されているダイジェスト値は、元のダイジェスト値と比較して切り捨てられます。

ステートメントダイジェストの詳細については、セクション27.10「パフォーマンススキーマのステートメントダイジェストとサンプリング」を参照してください。

max_error_count

SHOW ERRORS および SHOW WARNINGS ステートメントで表示するために格納されるエラー、警告および情報メッセージの最大数。 これは診断領域内の条件領域の数と同じで、GET DIAGNOSTICS によって調査できる条件数と同じです。

max_execution_time

SELECT ステートメントの実行タイムアウト (ミリ秒)。 値が 0 の場合、タイムアウトは有効になりません。

max_execution_time は次のように適用されます:

max_heap_table_size

この変数は、ユーザーが作成した MEMORY テーブルの増加が許可される最大サイズを設定します。 この変数の値は MEMORY テーブルの MAX_ROWS 値を計算するために使用されます。 この変数を設定しても、既存の MEMORY テーブルに影響しませんが、CREATE TABLE などのステートメントでテーブルを再作成したり、ALTER TABLE または TRUNCATE TABLE でテーブルを変更したりした場合は影響します。 サーバーを再起動しても、既存の MEMORY テーブルの最大サイズがグローバルの max_heap_table_size 値に設定されます。

この変数は、内部インメモリーテーブルのサイズを制限するために tmp_table_size と一緒に使用されることもあります。 セクション8.4.4「MySQL での内部一時テーブルの使用」を参照してください。

max_heap_table_size は複製されません。 詳しくは、セクション17.5.1.21「レプリケーションと MEMORY テーブル」およびセクション17.5.1.39「レプリケーションと変数」を参照してください。

max_insert_delayed_threads

この変数は、max_delayed_threads のシノニムです。

このシステム変数は非推奨です (DELAYED の挿入はサポートされていないため)。将来のリリースで削除される予定です。

max_join_size

検査が必要となる行数 (単一テーブルステートメントの場合) または行の組み合わせの数 (複数テーブルステートメントの場合) が、max_join_size をおそらく超えるか、ディスクシークが max_join_size 回を超えて実行される可能性があるステートメントを許可しません。 この値を設定することで、キーが適切に使用されず長い時間がかかりそうなステートメントをキャッチできます。 ユーザーが、WHERE 句のない結合、長い時間がかかる結合、または数百万行を返す結合を実行する傾向がある場合にこれを設定します。 詳細は、セーフ更新モードの使用 (--safe-updates)を参照してください。

この変数を DEFAULT 以外の値に設定すると、sql_big_selects の値が 0 にリセットされます。 sql_big_selects 値を再設定すると、max_join_size 変数は無視されます。

max_length_for_sort_data

この変数は、オプティマイザの変更によって廃止され、効果がないため、MySQL 8.0.20 では非推奨になりました。 以前は、使用する filesort アルゴリズムを決定するインデックス値のサイズに対するカットオフとして機能していました。 セクション8.2.1.16「ORDER BY の最適化」を参照してください。

max_points_in_geometry

ST_Buffer_Strategy() 関数に対する points_per_circle 引数の最大値。

max_prepared_stmt_count

この変数は、サーバー内のプリペアドステートメントの総数を制限します。 これは、大量のステートメントを作成することによってサーバーの実行するメモリーを不足させることに基づくサービス妨害攻撃の可能性がある環境で使用できます。 値が現在のプリペアドステートメントの数より低く設定された場合、既存のステートメントは影響を受けずに使用できますが、現在の数が制限を下回るまで新しいステートメントを作成できません。 値を 0 に設定すると、プリペアドステートメントが無効になります。

max_seeks_for_key

キーに基づいて行を参照するとき、推定されるシークの最大数を制限します。 MySQL オプティマイザは、インデックスをスキャンすることによってテーブル内で一致する行を検索するとき、インデックスの実際のカーディナリティーに関係なく、この数を超えるキーシークは不要であると推定します (セクション13.7.7.22「SHOW INDEX ステートメント」を参照してください)。 これを低い値 (100 など) に設定することで、MySQL でテーブルスキャンよりもインデックスを優先するように強制できます。

max_sort_length

データ値をソートするときに使用するバイト数。 サーバーは、各値の最初の max_sort_length バイトのみを使用し、残りは無視します。 したがって、最初の max_sort_length バイトの後にのみ異なる値は、GROUP BY、ORDER BY および DISTINCT 操作で等しいと比較されます。

max_sort_length の値を増やすには、sort_buffer_size の値も増やす必要があります。 詳細は、セクション8.2.1.16「ORDER BY の最適化」を参照してください

max_sp_recursion_depth