目的：
サーバーの現在のステータスに応じてMysqlのシステムパラメータを変更することにより、サーバーの既存のリソースを合理的に利用でき、MySQLのパフォーマンスを合理的に向上させることができます。
2.サーバーパラメーター：
32Gメモリ、4 CPU、それぞれ8コア。
3.MySQLの現在のインストールステータス。
MySQL目前安装，用的是MySQL默认的最大支持配置。拷贝的是my-huge.cnf.编码已修改为UTF-8.具体修改及安装MySQL,可以参考<<Linux系统上安装MySQL 5.5>>帮助文档。
4.MySQL構成を変更します
MySQL構成ファイルmy.cnfを開きます
vi /etc/my.cnf
4.1MySQLの非キャッシュパラメータ変数の導入と変更
4.1.1 back_logパラメーター値の変更：デフォルト値の50から500を変更します（接続あたり256kb、占有：125M）
back_log=500
back_log値は、MySQLが新しいリクエストへの応答を一時的に停止する前に、短期間にスタックに保存できるリクエストの数を示します。つまり、MySqlの接続データがmax_connectionsに達すると、新しいリクエストがスタックに保存され、接続がリソースを解放するのを待ちます。スタックの数はback_logです。待機している接続の数がback_logを超えると、接続リソースを付与しないでください。接続されたプロセスの場合、認証されていないユーザー| xxx.xxx.xxx.xxx | NULL |接続| NULL |ログイン| NULLが報告されます。
back_log値は、TCP / IP接続のリスニングキューのサイズを超えることはできません。を超える場合は無効です。現在のシステムのTCP / IP接続のリスニングキューのサイズを確認してください。コマンド：cat / proc / sys / net / ipv4 / tcp_max_syn_backlog現在のシステムは1024です。Linuxシステムの場合、推奨される設定は512未満の整数です。
システムカーネルパラメータを変更します。）http://www.51testing.com/html/64/n-810764.html
現在のmysqlシステムのデフォルトのback_log値を表示するには、次のコマンドを実行します。
show variables like 'back_log'; 查看当前数量
4.1.2wait_timeoutパラメーター値をデフォルトの8時間から30分に変更します。（今回は使用しません）
wait_timeout=1800（单位为妙）
パラメータwait-timeoutについての私の理解：MySQLクライアントのデータベース接続がアイドル状態である最大時間。
簡単に言うと、MySQL接続が一定時間以上アイドル状態になると、強制的に閉じられます。MySQLのデフォルトの待機タイムアウト値は8時間であり、結果値は「wait_timeout」;のようなコマンドshowvariablesを介して表示できます。
この値を設定することは非常に意味があります。たとえば、Webサイトに多数のMySQLリンク要求があり（各MySQL接続にはメモリリソースが必要です）、プログラムが原因で多数の接続要求がアイドル状態になっています。または、MySQLが接続の最大数を超え、新しい接続を作成できず、「接続が多すぎます」というエラーが発生します。設定する前に、MYSQLのステータスを確認できます（show processlistを使用できます）。MYSQLに多数のスリーププロセスがあることがよくある場合は、wait-timeout値を変更する必要があります。
Interactive_timeout：サーバーがインタラクティブ接続を閉じる前にアクティビティを待機する秒数。対話型クライアントは、mysql_real_connect（）のCLIENT_INTERACTIVEオプションを使用するクライアントとして定義されます。
wait_timeout：サーバーが非対話型接続を閉じる前にアクティビティを待機する秒数。スレッドが開始すると、セッションwait_timeout値は、クライアントタイプ（mysql_real_connect（）の接続オプションCLIENT_INTERACTIVEで定義）に応じて、グローバルwait_timeout値またはグローバルinteractive_timeout値に従って初期化されます。
これらの2つのパラメーターは一緒に使用する必要があります。それ以外の場合、wait_timeoutのみの設定は無効です
4.1.3 max_connectionsパラメータ値をデフォルトの151から3000（750M）に変更します。
max_connections=3000
max_connectionsは、MySqlの最大接続数を示します。サーバーの同時接続要求の数が比較的多い場合は、この値を増やして並列接続の数を増やすことをお勧めします。もちろん、これは次の状況に基づいています。接続数が多いと接続数が増えるため、マシンはサポートできます。MySqlは接続ごとに接続バッファーを提供するため、より多くのメモリが消費されるため、値を適切に調整する必要があり、値を増やすことはできません。盲目的に。'conn％'ワイルドカードを使用して、現在の状態の接続数を表示し、この値の値を決定できます。
MySQLサーバーで許可される接続の最大数は16384です。
システム内の現在の最大接続数を表示します。
show variables like 'max_connections';
4.1…4max_user_connections値をデフォルトの0から800に変更します
max_user_connections=800
max_user_connectionsは、各データベースユーザーの最大接続数を示します
特定のアカウントのすべてのクライアントがMYSQLサービスに並列に接続するための並列接続の最大数。簡単に言えば、同じアカウントが同時にmysqlサービスに接続できる接続の最大数を指します。0に設定すると、制限がないことを意味します。
現在のデフォルト値は0無制限です。
ちなみに、Max_used_connectionsの概要は次のとおりです。これは、mysqlサービスの開始から現在までの同時の並列接続の最大数を指します。現在の接続状態ではなく、比較値です。過去のある時点で、同時にMYSQLサービスに接続された1000のリクエストがあり、そのような大きな同時リクエストがなかった場合、Max_used_connections = 1000です。show変数のmax_user_connectionsとの違いに注意してください。デフォルトは0で、無限を意味します。
max_user_connections値を表示する
show variables like 'max_user_connections';
4.1.5thread_concurrency値を現在のデフォルト値の8から64に変更します
thread_concurrency=64
thread_concurrencyの値が正しいかどうかは、MySQLのパフォーマンスに大きな影響を与えます。複数のCPU（または複数のコア）の場合、thread_concurrencyの値を誤って設定すると、MySQLが複数のCPUを十分に活用できなくなります（または複数のコア）と同じように見える一度に1つのCPU（またはコア）のみが機能しています。
Thread_concurrencyはCPUコアの数の2倍に設定する必要があります。たとえば、デュアルコアCPUがある場合、thread_concurrencyは4である必要があり、2つのデュアルコアCPUの場合、thread_concurrencyの値は8である必要があります。
例：上記の導入私達の現在のシステムの構成によれば、我々は8つのコアをそれぞれ有する4つのCPUがあることを知っている上記計算規則によれば、ここでなければならない：4 8 2 = 64
システムの現在のthread_concurrencyデフォルト設定コマンドを表示します。
show variables like 'thread_concurrency';
4.1.6このパラメーターなしで、デフォルトでコメントアウトされるskip-name-resolveを追加します。
skip-name-resolve
skip-name-resolve：MySQLが外部接続のDNS解決を実行することを禁止します。このオプションを使用すると、MySQLがDNS解決を実行する時間をなくすことができます。ただし、このオプションが有効になっている場合は、すべてのリモートホスト接続認証でIPアドレスモードを使用する必要があります。有効にしないと、MySQLは接続要求を正常に処理できません。
4.1.7スキップネットワーク、デフォルトでコメントアウト。そのようなパラメータはありません。（今回はダメ）
skip-networking建议被注释掉，不要开启
このオプションを有効にすると、MySQLのTCP / IP接続モードを完全に閉じることができます。WEBサーバーがリモート接続を介してMySQLデータベースサーバーにアクセスする場合は、このオプションを有効にしないでください。そうしないと、正常に接続できません。
4.1.8 default-storage-engine（MySQLのデフォルトのストレージエンジンを設定します）
default-storage-engine = InnoDB（InnoDBタイプを設定します。また、MyISAMタイプを設定することもできます）
データベースとテーブルを作成するためのデフォルトのストレージタイプを設定します
show table status like ‘tablename’显示表的当前存储状态值
MySQLのストレージステータスとデフォルトのストレージステータスを表示する
show engines;
テーブルを作成し、ストレージタイプを指定します
CREATE TABLE mytable (id int, title char(20)) ENGINE = INNODB;
テーブルストレージタイプを変更します。
Alter table tableName engine =engineName
備考：設定後、以下の電源を入れてください。
# Uncomment the following if you are using InnoDB tables
innodb_data_home_dir = /var/lib/mysql
#innodb_data_file_path = ibdata1:1024M;ibdata2:10M:autoextend（要注释掉，否则会创建一个新的把原来的替换的。）
innodb_log_group_home_dir = /var/lib/mysql
# You can set .._buffer_pool_size up to 50 - 80 %
# of RAM but beware of setting memory usage too high
innodb_buffer_pool_size = 1000M
innodb_additional_mem_pool_size = 20M
# Set .._log_file_size to 25 % of buffer pool size
innodb_log_file_size = 500M
innodb_log_buffer_size = 20M
innodb_flush_log_at_trx_commit = 0
innodb_lock_wait_timeout = 50
設定後、MySQLインストールディレクトリのアドレスの下にあるib_logfile0とib_logfile1を削除することを忘れないでください（現在、デフォルトでインストールされているため、アドレスは/ var / lib / mysql /です）。それ以外の場合、MySQLの再起動は開始に失敗します。
4.2MySQLキャッシュ変数の導入と変更
データベースはIOを集中的に使用するアプリケーションであり、その主な責任はデータの管理と保存です。また、メモリからデータベースを読み取る時間はマイクロ秒のレベルであり、通常のハードディスクからIOを読み取る時間はミリ秒のレベルであることがわかっています。この2つの違いは3桁です。したがって、データベースを最適化するために最適化する必要がある最初のステップはIOであり、可能な限りディスクIOをメモリIOに変換します。この記事では、最初に、MySQLデータベースのIO関連パラメーター（キャッシュパラメーター）の観点から、IO最適化に使用できるパラメーターについて説明します。
4.2.1グローバルキャッシュ
MySQLの起動時に割り当てられ、常に存在するグローバルキャッシュ。現在、key_buffer_size（デフォルト値：402653184、つまり384M）、innodb_buffer_pool_size（デフォルト値：134217728、つまり128M）、innodb_additional_mem_pool_size（デフォルト値：8388608、つまり8M）、innodb_log_buffer_size（デフォルト値：8388608、つまり8M（デフォルト値）があります。 ：8388608）、query_cache_size）、値：33554432、つまり：32M）など5。合計：560M。
これらの変数値は、次のようなコマンドで表示できます：「変数名」のような変数を表示します;。
4.2.1.1：key_buffer_size、このシステムは現在384Mであり、400Mに変更できます
key_buffer_size=400M
key_buffer_sizeは、インデックスブロックに使用されるバッファのサイズです。これを増やすと、より良いインデックスを取得でき（すべての読み取りと複数の書き換えに対して）、MyISAM（MySQLテーブルストレージの一種であり、表示できます）のパフォーマンスに最大の影響を与えます。 Baiduなどの詳細）パラメータの1つ。大きくしすぎると、システムがページングを開始し、実際に速度が低下します。厳密に言えば、データベースのインデックス処理の速度、特にインデックスの読み取り速度を決定します。メモリが約4GBのサーバーの場合、このパラメーターは256Mまたは384Mに設定できます。
key_buffer_sizeの設定が適切かどうかを確認するにはどうすればよいですか？通常、Key_read_requestsとKey_readsのステータス値を確認できます.key_reads / key_read_requestsの比率は、1：100、1：1000など、できるだけ低くする必要があります。 1：10000。その値は、次のコマンドで確認できます。'key_read％ 'のようなステータスを表示します。
たとえば、システムの現在のkey_read値とkey_read_request値を表示します。
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| Key_read_requests | 28535 |
| Key_reads | 269 |
+-------------------+-------+
28535の要求があり、269の要求がメモリに見つからず、ハードディスクからインデックスを直接読み取ることがわかっています。
キャッシュミスの確率は、0.94％= 269/28535 * 100％です。通常、ミスの確率は0.1よりも優れています。0.1よりはるかに大きいので、効果が良くないことがわかります。ヒット率が0.01未満の場合は、key_buffer_size値を適切に変更することをお勧めします。
http://dbahacker.com/mysql/innodb-myisam-compare（InnoDBとMyISAMの6つの違い）
http://kb.cnblogs.com/page/99810/（ストレージエンジンの概要を参照）
MyISAM、InnoDB、MyISAMマージ引擎、InnoDB、メモリ（ヒープ）、アーカイブ
4.2.1.2：innodb_buffer_pool_size（デフォルトは128M）
innodb_buffer_pool_size=1024M(1G)
innodb_buffer_pool_size：InnoDBテーブルのパフォーマンスに最大の影響を与えるパラメーター。関数はKey_buffer_sizeと同じです。InnoDBが占有するメモリは、ページキャッシュデータの格納に使用されるinnodb_buffer_pool_sizeに加えて、通常の状況では約8％のオーバーヘッドもあり、主に各キャッシュページフレーム、アダプティブハッシュ、その他のデータ構造の説明で使用されます。安全に閉じて開始する時々回復する必要がある場合は、メモリの別の12％を回復に使用する必要があり、2つを合計するとオーバーヘッドのほぼ21％になります。仮定：Innodb_buffer_pool_sizeが12Gの場合、InnoDBは最大で14.5Gのメモリを占有する可能性があります。システムに16Gしかなく、MySQLのみを実行し、MySQLがInnoDBのみを使用する場合、
次に、12G for MySQLを開いて、メモリを最大限に活用します。
さらに、InnoDBとMyISAMストレージエンジンは異なります。MyISAMのkey_buffer_sizeはインデックスキーのみをキャッシュできますが、innodb_buffer_pool_sizeはデータブロックとインデックスキーをキャッシュできます。このパラメーターのサイズを適切に増やすと、InnoDBテーブルのディスクI / Oを効果的に減らすことができます。
InnoDBテーブルを操作すると、返されるすべてのデータまたはデータ削除のプロセスで使用されるインデックスブロックは、このメモリ領域を通過します。
キャッシュヒット率は（Innodb_buffer_pool_read_requests – Innodb_buffer_pool_reads）/ Innodb_buffer_pool_read_requests * 100％で計算でき、innodb_buffer_pool_sizeパラメーターサイズはヒット率に応じて最適化するように調整できます。値は、次のコマンドで確認できます。showstatus like'Innodb_buffer_pool_read％ ';
たとえば、システム内の現在のシステムを表示します
| Innodb_buffer_pool_read_requests | 1283826 |
| Innodb_buffer_pool_reads | 519 |
+---------------------------------------+---------+
ヒット率は99.959％=（1283826-519）/ 1283826 * 100％です。ヒット率が高いほど良いです。
4.2.1.3：innodb_additional_mem_pool_size（デフォルトは8M）
innodb_additional_mem_pool_size=20M
innodb_additional_mem_pool_sizeは、InnoDBストレージエンジンがデータディクショナリ情報と一部の内部データ構造を格納するために使用するメモリスペースのサイズを設定するため、MySQLインスタンスに多数のデータベースオブジェクトがある場合、このパラメーターのサイズを適切に調整する必要があります。アクセス効率を向上させるために、すべてのデータをメモリに保存できることを確認してください。
このパラメータサイズが十分であるかどうかは比較的簡単にわかります。これは、サイズが小さすぎると、MySQLがデータベースのエラーログに警告情報を記録し、このパラメータのサイズを調整する必要があることがわかるためです。
現在のシステムmysqlのエラーログcat / var / lib / mysql / machine name.errorを確認し、多くの警告警告があることを確認してください。したがって、20Mに調整する必要があります。
MySQLのマニュアルによると、2Gメモリを搭載したマシンの場合、推奨値は20Mです。
100Mの32GRAM
4.2.1.4：innodb_log_buffer_size（デフォルトは8M）
innodb_log_buffer_size=20M
innodb_log_buffer_sizeこれは、InnoDBストレージエンジンのトランザクションログによって使用されるバッファーです。Binlogバッファーと同様に、InnoDBがトランザクションログを書き込むとき、パフォーマンスを向上させるために、最初に情報をInnofbログバッファーに書き込みます。innodb_flush_log_trx_commitパラメーターによって設定された対応する条件（またはログバッファーがいっぱい）の後でのみ、書き込まれますログはファイルに書き込まれます（またはディスクに同期されます）。使用できる最大メモリスペースは、innodb_log_buffer_sizeパラメーターを使用して設定できます。
InnoDBがログをログディスクファイルに書き込む前のバッファーのサイズ。理想的な値は1Mから8Mです。大きなログバッファにより、ログをディスクに保存せずに、トランザクションがコミット（コミット）されるまでトランザクションを実行できます。したがって、大きなトランザクション処理がある場合、大きなログバッファを設定すると、ディスクI / Oを減らすことができます。my.cnfで数値形式で設定します。
デフォルトは8MBですが、頻繁なシステムでは4MB〜8MBまで適切に増やすことができます。もちろん、前述のように、このパラメーターは実際には他のフラッシュパラメーターに関連しています。一般的に、32MBを超えることはお勧めしません
注：innodb_flush_log_trx_commitパラメーターは、InnoDBログの書き込みパフォーマンスに非常に重大な影響を及ぼします。デフォルト値は1です。このパラメーターは0、1、2に設定でき、説明は次のとおりです。
0：ログバッファ内のデータは1秒に1回の頻度でログファイルに書き込まれ、ファイルシステムは同時にディスクに同期されますが、各トランザクションのコミットによってログバッファがトリガーされることはありません。ログファイルへ。リフレッシュまたはファイルシステムからディスクへのリフレッシュ操作。
1：ログバッファ内のデータは、トランザクションが送信されるたびにログファイルに書き込まれ、ファイルシステムのディスクへの同期もトリガーされます。
2：トランザクションコミットはログバッファのログファイルへのフラッシュをトリガーしますが、ディスクファイルシステムのディスクへの同期はトリガーしません。さらに、ファイルシステムからディスクへの同期操作が毎秒行われます。
実際のテストでは、この値がデータの挿入速度に大きな影響を与えることがわかりました.2に設定すると、10000レコードを挿入するのに2秒しかかからず、0に設定すると、1秒しかかかりません。 1に設定すると、229秒かかります。したがって、MySQLマニュアルでは、挿入操作を可能な限り1つのトランザクションに組み合わせることも推奨しています。これにより、速度が大幅に向上する可能性があります。MySQLのマニュアルによると、最新のトランザクションを失うリスクがある場合は、この値を0に設定できます。
4.5.1.5：query_cache_size（デフォルトは32M）
query_cache_size=40M
query_cache_size：主にMySQLのResultSetをキャッシュするために使用されます。これはSQLステートメント実行の結果セットであるため、selectステートメントにのみ使用できます。クエリキャッシュ機能をオンにしたとき、MySQLがselectステートメントの要求を受信した後、ステートメントがクエリキャッシュの要件を満たしているかどうか（クエリキャッシュが許可されていないこと、またはクエリキャッシュの使用が明示的に記述されていることは明示されていません） ）、MySQL受信したselectステートメントを事前設定されたHASHアルゴリズムに従って文字列として直接ハッシュし、クエリキャッシュにキャッシュされているかどうかを直接チェックします。つまり、すでにキャッシュにある場合、selectリクエストはデータを直接返すため、後続のすべてのステップ（SQLステートメントの解析、オプティマイザーの最適化、ストレージエンジンからのデータのリクエストなど）が省略されます。パフォーマンスが向上します。MySQLユーザーマニュアルによると、クエリバッファリングを使用すると、最大238％の効率を達成できます。
もちろん、クエリキャッシュにも致命的な欠陥があります。つまり、テーブルのデータを変更すると、テーブルを参照するすべてのselectステートメントがクエリキャッシュにキャッシュされたデータを無効にします。したがって、データが非常に頻繁に変更される場合、クエリキャッシュを使用するとメリットが上回る可能性があります
クエリキャッシュを使用するには、複数のパラメータを使用する必要があります。最も重要なパラメータは、query_cache_sizeとquery_cache_typeです。前者はResultSetをキャッシュするためのメモリサイズを設定し、後者はクエリキャッシュが使用されるコンテキストを設定します。過去の経験では、基本的に変更されていないデータをキャッシュするためのMySQLデータベースでない場合、query_cache_sizeは通常256MBがより適切なサイズです。もちろん、これはクエリキャッシュのヒット率を計算することで調整できます（Qcache_hits /（Qcache_hits + Qcache_inserts）* 100））。query_cache_typeは、それぞれ0（OFF）、1（ON）、または2（DEMOND）に設定できます。これは、クエリキャッシュがまったく使用されないことを意味します。クエリキャッシュを使用しない明示的な要求を除くすべての選択（ sql_no_cache）はクエリキャッシュを使用します。クエリキャッシュ（sql_cacheを使用）は、表示が必要な場合にのみ使用します。Qcache_lowmem_prunesの値が非常に大きい場合は、バッファリングが頻繁に発生することを示します。Qcache_hitsの値も非常に大きい場合は、クエリバッファが非常に頻繁に使用されることを示し、この時点でバッファサイズを増やす必要があります。
ヒット率に応じて調整します（Qcache_hits /（Qcache_hits + Qcache_inserts）* 100））。通常、大きすぎることはお勧めしません。256MBはほぼ同じです。大きな構成の静的データは適切に調整できます。
次のコマンドを使用できます：「Qcache_％」のようなステータスを表示;現在のシステムを表示するにはクエリキャッチ使用量サイズ
| Qcache_hits | 1892463 |
| Qcache_inserts | 35627
98.17％ヒット率= 1892463 /（1892463 +35627）* 100
4.2.2ローカルキャッシュ
MySqlは、グローバルバッファに加えて、接続ごとに接続バッファも発行します。MySQLサーバーに接続する各スレッドには、独自のバッファーが必要です。スレッドがアイドル状態の場合でも、デフォルトのスレッドスタック、ネットワークキャッシュなどを使用する場合でも、おそらくすぐに256Kを割り当てる必要があります。トランザクションの開始後、さらにスペースを追加する必要があります。小さなクエリを実行すると、指定したスレッドに少量のメモリ消費が追加されるだけです。ただし、スキャン、並べ替え、一時テーブルの要求など、データテーブルに対して複雑な操作を行う場合は、read_buffer_sizeについて割り当てる必要があります。
Sort_buffer_size、read_rnd_buffer_size、tmp_table_sizeメモリスペース。ただし、これらは必要な場合にのみ割り当てられ、これらの操作が完了した後に解放されます。一部はすぐに別々のチャンクに割り当てられます。tmp_table_sizeは、MySQLがこの操作に割り当てることができる最大メモリスペースと同じくらい大きい場合があります
。ここで考慮すべきことが複数あることに注意してください。たとえば、サブクエリを処理するために、同じタイプの複数のキャッシュが割り当てられる場合があります。MyISAMテーブルでバッチ挿入が行われる場合、一部の特別なクエリのメモリ使用量が大きくなる可能性があります
Bulk_insert_buffer_sizeメモリを割り当てる必要がある場合、ALTER TABLE、OPTIMIZE TABLE、REPAIR TABLEコマンドを実行すると、myisam_sort_buffer_sizeメモリを割り当てる必要があります。
4.2.2.1：read_buffer_size（デフォルト値：2097144または2M）
read_buffer_size=4M
read_buffer_sizeは、MySqlが読み取るバッファーのサイズです。テーブルのシーケンシャルスキャンのリクエストは読み取りバッファを割り当て、MySqlはそれにメモリバッファを割り当てます。read_buffer_size変数はこれを制御します
バッファのサイズ。テーブルの順次スキャン要求が非常に頻繁であり、頻繁なスキャンが遅すぎると思われる場合は、この変数の値とメモリバッファーのサイズを増やすことで、パフォーマンスを向上させることができます。
4.2.2.2：sort_buffer_size（デフォルト値：2097144または2M）
sort_buffer_size=4M
sort_buffer_sizeは、MySqlがソートを実行するために使用するバッファーサイズです。ORDER BYの速度を上げたい場合は、最初に、追加のソート段階の代わりにMySQLにインデックスを使用させることができるかどうかを確認してください。そうでない場合は、sort_buffer_size変数のサイズを大きくしてみてください。
4.2.2.3：read_rnd_buffer_size（デフォルト値：8388608または8M）
read_rnd_buffer_size=8M
read_rnd_buffer_sizeは、MySqlのランダムな読み取りバッファーサイズです。行が任意の順序（たとえば、ソート順）で読み取られると、ランダムな読み取りバッファーが割り当てられます。ソートおよびクエリを実行する場合、MySqlは最初にバッファをスキャンして、ディスク検索を回避し、クエリ速度を向上させます。大量のデータをソートする必要がある場合は、値を適切に増やすことができます。ただし、MySqlはクライアント接続ごとにバッファスペースを発行するため、メモリが開かないように、この値を適切に設定するようにしてください。
ピンが大きすぎます。
4.2.2.4：tmp_table_size（デフォルト値：8388608すなわち：16M）
tmp_table_size=16M
tmp_table_sizeは、MySqlのヒープ（スタック）テーブルバッファサイズです。すべてのユニオンは1つのDML命令で完了し、ほとんどのユニオンは一時テーブルなしでも完了できます。ほとんどの一時テーブルはに基づいています
保存された（HEAP）テーブル。レコード長が長い一時テーブル（すべての列の長さの合計）またはBLOB列を含むテーブルは、ハードディスクに格納されます。内部ヒープ（スタック）テーブルのサイズがtmp_table_sizeを超える場合、MySQLは自動的に
メモリ内のヒープテーブルを、ハードディスクに基づいてMyISAMテーブルに自動的に変更します。tmp_table_sizeオプションを設定して、一時テーブルのサイズを増やすこともできます。つまり、値を増やすと、MySqlは同時にヒープテーブルのサイズを増やします。これは改善できます。
リンククエリ速度の影響。
4.2.2.5：record_buffer :(デフォルト値:)
Record_buffer順次スキャンを実行する各スレッドは、スキャンするテーブルごとにこのサイズのバッファーを割り当てます。多数の順次スキャンを実行する場合は、この値を増やすことをお勧めします。デフォルト値は131072です
（128K）
4.2.3その他のキャッシュ：
4.2.3.1：table_cache（デフォルト：512）
TABLE_CACHE（5.1.3以降のバージョンではTABLE_OPEN_CACHEとも呼ばれます）
table_cacheは、テーブルキャッシュのサイズを指定します。MySQLがテーブルにアクセスするときはいつでも、テーブルバッファに空きがある場合は、テーブルが開かれてテーブルに配置されるため、テーブルの内容にすばやくアクセスできます。ピーク時の状態値Open_tablesとOpened_tablesを確認することで、table_cacheの値を増やす必要があるかどうかを判断できます。open_tablesがtable_cacheと等しく、opened_tablesが増加していることがわかった場合は、table_cacheの値を増やす必要があります（上記のステータス値は、SHOW STATUS LIKE'Open％tables 'を使用して取得できます）。table_cacheをやみくもに大きな値に設定することはできないことに注意してください。設定が高すぎると、ファイル記述子が不十分になり、パフォーマンスが不安定になったり、接続に失敗したりする可能性があります。
SHOW STATUS LIKE 'Open%tables';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Open_tables | 356 |
| Opened_tables | 0 |
+---------------+-------+
2 rows in set (0.00 sec)
open_tablesは、現在開いているテーブルキャッシュの数を表します。テーブルのフラッシュ操作が実行されると、システムは、この状態の値を減らすために、現在使用されていないテーブルキャッシュの一部を閉じます。
opend_tablesは、開かれたテーブルキャッシュの数を表し、常に累積されます。テーブルのフラッシュ操作が実行されても、値は減少しません。
mysqlのデフォルトインストールの場合、2Gメモリを搭載したマシンではtable_cacheの値はデフォルトで256〜512です。マシンに4Gメモリがある場合、デフォルト値は2048ですが、これは間違いなくマシンメモリが大きいことを意味します。この値table_cacheが増加すると、mysqlはSQLへの応答が速くなり、必然的に、より多くのデッドロック（デッドロック）が生成され、データベース操作のセット全体が遅くなり、パフォーマンスに深刻な影響を与えるため、より大きくする必要があります。したがって、通常の保守では、ライブラリの実際の状況に基づいて判断を下し、保守するライブラリに最適なtable_cache値を見つける必要があります。
MySQLはマルチスレッドメカニズムであるため、パフォーマンスを向上させるために、各スレッドは、共有するのではなく、必要なテーブルのファイル記述子を個別に開きます。もちろん、異なるストレージエンジンの処理方法は異なります。
myisamテーブルエンジンでは、データファイルの記述子は共有されませんが、インデックスファイルの記述子はすべてのスレッドで共有されます。Innodbは、使用されるテーブルスペースのタイプに関連しています。共有テーブルスペースの場合は、もちろん、実際には1つのデータファイルであり、独立したテーブルスペースよりも少ないデータファイル記述子を占有します。
mysqlマニュアルに記載されている推奨サイズは次のとおりです。table_cache= max_connections * n
nは、クエリステートメント内のテーブルの最大数を表し、いくつかの追加のファイル記述子は、一時テーブルおよびファイル用に予約する必要があります。
このデータは多くの質問を受けています。十分なtable_cacheで十分です。Opened_tablesの値を確認してください。この値が非常に大きい場合、または値が急速に大きくなる場合は、table_cacheを増やすことを検討する必要があります。
table_cache：すべてのスレッドによって開かれたテーブルの数。この値を増やすと、mysqldに必要なファイル記述子の数を増やすことができます。デフォルト値は64です。
4.2.3.2 thread_cache_size（サーバースレッドキャッシュ）
thread_cache_size=64
デフォルトのthread_cache_size = 8ですが、多くの構成例の値は通常32、64、または128です。このパラメーターは最適化に役立つはずなので、次のことを確認しました。
調査の結果、サーバースレッドキャッシュのthread_cache_sizeが設定されていないか、設定が小さすぎることが判明しました。この値は、キャッシュに保存されているスレッド数を再利用できることを示しています。キャッシュに空きがある場合接続が切断されると、クライアントスレッドがキャッシュに配置され、スレッドが再度要求されると、要求がキャッシュから読み取られます。キャッシュが空の場合、または新しい要求の場合、スレッドが再作成されます。多くの新しいスレッドがあり、この値を増やします。システムパフォーマンスを向上させます。ConnectionsとThreads_created状態変数を比較することで、この変数の役割を確認できます。（–>は調整する値を示します）物理メモリ設定規則に従って、次のようになります。
1G —> 8
2G —> 16
3G —> 32 >3G —> 64
mysql> show status like 'thread%';
+——————-+——-+
| Variable_name | Value |
+——————-+——-+
| Threads_cached | 0 | <—当前被缓存的空闲线程的数量
| Threads_connected | 1 | <—正在使用（处于连接状态）的线程
| Threads_created | 1498 | <—服务启动以来，创建了多少个线程
| Threads_running | 1 | <—正在忙的线程（正在查询数据，传输数据等等操作）
+——————-+——-+
起動後にデータベースが接続された回数を確認しますか？
mysql> show status like '%connection%';
+———————-+——-+
| Variable_name | Value |
+———————-+——-+
| Connections | 1504 | –>服务启动以来，历史连接数
| Max_used_connections | 2 |
+———————-+——-+
接続スレッドプールのヒット率で設定値が適切かどうかを判断しますか？ヒット率は90％以上で、リーズナブルな設定です。
（接続-Threads_created）/接続* 100％
著者：
リンクをかわす：https：//www.jianshu.com/p/c88a45c2f642