記事のディレクトリ
構成の最適化
MySQLパラメータの最適化は、さまざまなWebサイト、およびそれらのオンラインボリューム、アクセスボリューム、投稿数、ネットワーク状態、およびマシンハードウェア構成に関連しています。最適化を一度に完了することはできません。最高の効果を得るには、継続的な監視とデバッグが必要です。パフォーマンスの最適化に大きな影響を与える主な変数を以下に示します。これらは主に接続要求変数とバッファー変数に分けられます。
接続要求変数
1.max_connections
MySQLの最大接続数サーバーからの同時接続要求の数が比較的多い場合は、この値を増やして並列接続の数を増やすことをお勧めします。もちろん、これはマシンの状況に基づいています。接続数が多い場合、MySQL A接続バッファが接続ごとに提供され、より多くのメモリが消費されるため、サポートできます。したがって、設定値をやみくもに増やすのではなく、値を適切に調整する必要があります。
値が小さすぎる場合、エラー1040：接続数が多すぎるというエラーが頻繁に表示されます。合格できます。
mysql> show status like 'connections';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Connections | 3 |
+---------------+-------+
1 row in set (0.00 sec)
ワイルドカード文字は、現在の状態の接続数（MySQLに接続しようとしている接続数（接続が成功したかどうかに関係なく））をチェックして、この値の値を決定します。
mysql> show variables like 'max_connections';
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| max_connections | 151 | #最大连接数
+-----------------+-------+
1 row in set (0.00 sec)
mysql> show status like 'max_used_connections';
+----------------------+-------+
| Variable_name | Value |
+----------------------+-------+
| Max_used_connections | 3 | #响应的连接数
+----------------------+-------+
1 row in set (0.00 sec)
max_used_connections / max_connections * 100％（理想値≈85％）max_used_connectionsがmax_connectionsと同じ場合、max_connectionsの設定が低すぎるか、サーバー負荷の上限を超えています。10％未満の場合、設定が大きすぎます。
max_connectionsを設定する
方法は？方法1：
mysql> set GLOBAL max_connections=1000;
Query OK, 0 rows affected (0.00 sec)
mysql> show variables like 'max_connections';
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| max_connections | 1000 |
+-----------------+-------+
1 row in set (0.00 sec)
方法2：
/etc/my.cnfファイルを変更し、[mysqld]の下に次のコンテンツを追加します。たとえば、接続の最大数を500に設定します。
[root@mysqld01 ~]# cat /etc/my.cnf
[mysqld]
.....
max_connections = 500
#重启mysql服务
2.back_logMySQL
が一時的に保存できる接続の数。これは、メインのMySQLスレッドが短期間に大量の接続要求を取得した場合に機能します。MySQL接続データがmax_connectionsに達すると、接続がリソースを解放するのを待つために新しいリクエストがスタックに格納されます。スタックの数はback_logです。待機している接続の数がback_logを超えると、接続リソースは付与されません。back_log値は、MySQLが新しいリクエストへの応答を一時的に停止する前に、短期間にスタックに保存できるリクエストの数を示します。短期間に多くの接続があると予想される場合にのみ、接続を増やす必要があります。
ホストプロセスリスト（mysql> show full processlist）を観察すると、多数のxxxxx |認証されていないユーザー| xxx.xxx.xxx.xxx | NULL |接続| NULL |ログイン|
NULLプロセスが接続されていることがわかります。増やす必要がありますback_log値またはmax_connectionsの値を増やします。沿って
mysql> show variables like 'back_log'; #查看back_log的设置
// back_log値
を設定します[mysqld]の下に次のコンテンツを追加します
[root@mysqld01 ~]# tail -1 /etc/my.cnf
back_log = 150
重启mysqld
3.wait_timeoutおよびinteractive_timeoutwait_timeout wait_timeout
-MySQLが非対話型接続を閉じる前に待機する秒数を指しますinteractive_time-MySQLが対話型接続を閉じる前に待機する秒数を指します（端末のmysql管理に入るときなど）。 、インタラクティブ接続を使用している場合でも、このとき、操作がない時間がinteractive_timeで設定した時間を超えると、自動的に切断されます。デフォルト値は28800で、調整可能な値は7200です。
パフォーマンスへの影響：
wait_timeout：
- 設定が小さすぎると、接続がすぐに閉じられるため、一部の持続的接続が機能しなくなります
- 設定が大きすぎると、接続が長時間開かれやすくなります。showprocesslistの実行中に、スリープ状態の接続が多すぎて、接続エラーが多すぎることがあります。
- 一般に、wait_timeoutはできるだけ低くすることが望まれます。interactive_timeoutの設定は、Webアプリケーションにあまり影響を与えません。wait_timeoutとinteractive_timeoutを確認してください。
mysql> show variables like 'wait_timeout';
mysql> show variables like 'interactive_timeout';
// wait_timeoutとinteractive_timeoutの値を変更し、[mysqld]の下に次のコンテンツを追加します
[root@mysqld01 ~]# tail -2 /etc/my.cnf
wait_timeout=100
interactive_timeout=100
重启mysqld
バッファ変数
グローバルバッファ：
1.key_buffer_size
key_buffer_sizeは、インデックスバッファのサイズを指定します。これにより、インデックス処理の速度、特にインデックスの読み取り速度が決まります。ステータス値Key_read_requestsとKey_readsを確認することで、key_buffer_size設定が適切かどうかを知ることができます。key_reads
/ key_read_requestsの比率はできるだけ低くする必要があり、少なくとも1：100、1：1000の方が優れています（上記のステータス値は、SHOW STATUSLIKE'key_read％ 'を使用して取得できます）。
合計6つのインデックス読み取り要求があり、ハードディスクから直接インデックスを読み取り、インデックスミスキャッシュの確率を計算するための3つの要求がメモリに見つかりません：key_cache_miss_rate = Key_reads / Key_read_requests * 100％= 50％key_buffer_size MyISAMテーブル効果の場合のみ。MyISAMテーブルを使用せず、内部一時ディスクテーブルがMyISAMテーブルである場合でも、この値を使用する必要があります。チェックステータス値created_tmp_disk_tablesを使用して、詳細を知ることができます。
key_buffer_sizeの調整方法デフォルトの構成値は8388608（8M）、ホストには4GBのメモリ、調整可能な値は268435456（256MB）です。/etc/my.cnfファイルを変更し、[mysqld]の下に次のコンテンツを追加します。
[root@mysqld01 ~]# tail -1 /etc/my.cnf
key_buffer_size=268435456
//或key_buffer_size=256M
重启mysqld
2. query_cache_size
query_cache_size（クエリキャッシュの略でQC）MySQLは、クエリバッファを使用して、クエリ結果をバッファに格納します。将来、同じSELECTステートメント（大文字と小文字を区別）の場合、結果はバッファから直接読み取られます。SQLクエリがselectで始まる場合、MySQLサーバーはクエリキャッシュを使用しようとします。
注：2つのSQLステートメントは、違いが1文字である限り（たとえば、大文字と小文字が異なる、もう1つのスペースなど）、2つのSQLステートメントは異なるCACHEを使用します。
ステータス値「Qcache％」を確認することで、query_cache_size設定が適切かどうかを知ることができます（上記のステータス値は、「qcache％」のようなshow statusを使用して取得できます）。
mysql> show status like 'qcache%';
+-------------------------+---------+
| Variable_name | Value |
+-------------------------+---------+
| Qcache_free_blocks | 1 |
| Qcache_free_memory | 1031832 |
| Qcache_hits | 0 |
| Qcache_inserts | 0 |
| Qcache_lowmem_prunes | 0 |
| Qcache_not_cached | 1 |
| Qcache_queries_in_cache | 0 |
| Qcache_total_blocks | 1 |
+-------------------------+---------+
8 rows in set (0.02 sec)
Qcache_free_blocks：キャッシュ内の隣接するメモリブロックの数。値が大きく表示されている場合は、クエリキャッシュにメモリフラグメントが多いことを意味し、FLUSH QUERYCACHEはキャッシュ内のフラグメントを最適化して空きブロックを取得します。注：テーブルが更新されると、それに関連するキャッシュブロックが解放されます。ただし、このブロックは、キューの最後にない限り、キューに残っている可能性があります。FLUSH QUERY CACHEステートメントを使用して、空きブロックをクリアできます
Qcache_free_memory：クエリキャッシュに現在残っているメモリサイズ。このパラメータを使用すると、現在のシステムのクエリキャッシュのメモリサイズが十分であるかどうか、増やす必要があるかどうか、または大きすぎるかどうかをより正確に観察できます。
Qcache_hits：キャッシュがヒットした回数を示します。主にこの値を使用して、クエリキャッシュの効果を確認できます。数値が大きいほど、キャッシュ効果が高くなります。
Qcache_inserts：ミスしてから挿入する回数を示します。つまり、新しいSQL要求がキャッシュに見つからず、クエリ処理を実行する必要があります。クエリ処理が実行された後、結果がクエリキャッシュに挿入されます。このようなケースの数が多いほど、クエリキャッシュの適用が少なくなり、効果が不十分になります。もちろん、システムが起動した直後はクエリキャッシュは空ですが、これは正常です。
Qcache_lowmem_prunes：メモリ不足のためにクエリキャッシュからクリアされたクエリの数。「Qcache_lowmem_prunes」と「Qcache_free_memory」を組み合わせることで、システム内のクエリキャッシュのメモリサイズが本当に十分かどうか、メモリ不足のためにクエリが頻繁にスワップアウトされるかどうかをより明確に理解できます。この数値は長期間表示するのが最適です。
この数値が増加している場合は、断片化が非常に深刻であるか、メモリが非常に少ない可能性があることを意味します。（上記のfree_blocksとfree_memoryは、それがどの状況に属しているかを教えてくれます）
Qcache_not_cached：通常、これらのクエリがSELECTステートメントではないか、now（）などの関数を使用しているため、キャッシュに適していないクエリの数。
Qcache_queries_in_cache：現在のクエリキャッシュのキャッシュ内のクエリの数。
Qcache_total_blocks：現在のQueryCache内のブロック数。
// query_cacheに関するサーバー構成を確認しましょう
mysql> show variables like "%query_cache%";
+------------------------------+---------+
| Variable_name | Value |
+------------------------------+---------+
| have_query_cache | YES |
| query_cache_limit | 1048576 |
| query_cache_min_res_unit | 4096 |
| query_cache_size | 1048576 |
| query_cache_type | OFF |
| query_cache_wlock_invalidate | OFF |
+------------------------------+---------+
6 rows in set (0.00 sec)
上記から、query_cache_typeがオフになっていることがわかります。これは、クエリフィールドの解釈がキャッシュされていないことを意味します。
query_cache_limit：このサイズを超えるクエリはキャッシュされません
query_cache_min_res_unit：キャッシュブロックの最小サイズ、query_cache_min_res_unitの構成は「両刃の剣」です。デフォルトは4KBです。大きな値を設定すると、ビッグデータクエリに適しています。クエリがすべての場合小さなデータクエリであるため、メモリの断片化や無駄が発生しやすくなります。
query_cache_size：クエリキャッシュサイズ（注：QCストレージの最小単位は1024バイトであるため
、1024の倍数ではない値を設定すると、この値は1024の倍数に等しい最も近い値に丸められます。）
query_cache_type ：キャッシュの種類。キャッシュするクエリの種類を決定します。この値は任意に設定することはできません。数値に設定する必要があります。オプションの項目と説明は次のとおりです。
uery_cache_type三个参数的含义:
query_cache_type=0（OFF）关闭
query_cache_type=1（ON）缓存所有结果，除非select语句使用SQL_NO_CACHE禁用查询缓存
query_cache_type=2(DEMAND)，只缓存select语句中通过SQL_CACHE指定需要缓存的查询
0に設定すると、キャッシュはまったく役に立たないと言えます。これは、無効になっているのと同じです。1に設定すると、selectステートメントでSQL_NO_CACHEを使用してクエリのキャッシュを無効にしない限り、すべての結果がキャッシュされます。2に設定されている場合、キャッシュする必要のあるクエリのみがSQL_CACHEを介してselectステートメントで指定されます。
query_cache_wlock_invalidate：他のクライアントがMyISAMテーブルに書き込んでいるときに、クエリがクエリキャッシュにある場合は、キャッシュ結果を返すか、書き込み操作が完了するのを待ってからテーブルを読み取って結果を取得します。
クエリキャッシュの断片化率= Qcache_free_blocks / Qcache_total_blocks * 100％クエリキャッシュの断片化率が20％を超える場合、FLUSH QUERY CACHEを使用してキャッシュフラグメントを最適化するか、クエリがすべて小さいデータ量の場合はquery_cache_min_res_unitを減らすことができます。クエリキャッシュ使用率=（query_cache_size – Qcache_free_memory）/ query_cache_size * 100％クエリキャッシュ使用率が25％未満の場合、query_cache_sizeの設定が大きすぎて適切に削減できることを意味します。クエリキャッシュ使用率が80％を超え、Qcache_lowmem_prunesの場合> 50の場合、query_cache_sizeが少し小さいか、断片化が多すぎる可能性があることを意味します。クエリキャッシュヒット率= Qcache_hits /（Qcache_hits + Qcache_inserts）* 100％
クエリキャッシュの制限：a）すべてのサブクエリの外部クエリSQLをキャッシュできません; b）プロシージャ、関数、およびトリガーのクエリをキャッシュできません; c）実行するたびに異なる結果を得る可能性のある他の多くの関数を含むクエリできませんキャッシュされます。上記の制限を考慮して、クエリキャッシュを使用するプロセスでは、正確な設定で使用することをお勧めします。適切なテーブルのデータのみがクエリキャッシュに入力でき、特定のクエリ結果のみをキャッシュできます。
// query_cache_sizeを設定します
[root@mysqld01 ~]# tail -2 /etc/my.cnf
query_cache_size=256M
query_cache_type=1
//重启mysqld
3.max_connect_errors
max_connect_errorsは、MySQLのセキュリティ関連のカウンタ値です。ブルートフォースパスワードクラックを防ぐために、失敗したクライアントが多すぎるのを防ぐ役割があります。指定された回数を超えると、MYSQLサーバーはホストの接続要求を禁止します。 mysql server flush hostsコマンドを使用して、このホストの関連情報を再起動またはクリアします。max_connect_errorsの値は、パフォーマンスとは何の関係もありません。
/etc/my.cnfファイルを変更し、[mysqld] max_connect_errors = 20の下に次のコンテンツを追加します。MySQLServerを再起動して入力した後、設定が有効になっていることを確認します。
max_connect_errors=20
または
mysql> set GLOBAL max_connect_errors=20;
Query OK, 0 rows affected (0.00 sec)
mysql> show variables like 'max_connect_errors';
+--------------------+-------+
| Variable_name | Value |
+--------------------+-------+
| max_connect_errors | 20 |
+--------------------+-------+
1 row in set (0.00 sec)
4.sort_buffer_size
sort_buffer_sizeソートする必要のある各スレッドは、このサイズのバッファーを割り当てます。この値を増やすと、ORDERBYまたはGROUPBY操作が高速化されます。Sort_Buffer_Sizeは接続レベルのパラメータです。各接続（セッション）がこのバッファを初めて使用する必要がある場合、設定されたメモリが一度に割り当てられます。Sort_Buffer_Sizeは接続レベルのパラメーターであるため、可能な限り大きくはありません。設定が大きすぎる+同時実行性が高いと、システムメモリリソースが使い果たされる可能性があります。
例：500接続は500 * sort_buffer_size（2M）= 1Gメモリを消費します
// sort_buffer_sizeを設定します/etc/my.cnfファイルを変更し、[mysqld]の下に次のコンテンツを追加しますsort_buffer_size = 2M MySQL Serverを再起動した後、設定が有効になっていることを確認します。
5.max_allowed_packet
max_allowed_packet = 32M MySQLは、構成ファイルに従ってサーバーが受け入れるパケットサイズを制限します。大規模な挿入と更新がmax_allowed_packetパラメーターによって制限され、書き込みまたは更新の失敗が発生する場合があります。最大値は1GBで、1024の倍数を設定する必要があります。
6.join_buffer_size
join_buffer_size = 2Mテーブル間に関連付けられたキャッシュのサイズ。sort_buffer_sizeと同様に、このパラメーターに対応する割り当てられたメモリも各接続専用です。
7.thread_cache_size
thread_cache_size = 300サーバースレッドキャッシュ。この値は、キャッシュに保存されているスレッドの数を再利用できることを示します。接続が切断されると、クライアントスレッドはキャッシュに配置され、代わりに次のクライアントに応答します。破棄されている（前提キャッシュ数が上限に達していない）スレッドが再度要求された場合、要求はキャッシュから読み取られます。キャッシュが空の場合、または新しい要求の場合、スレッドが再作成されます。多くの新しいスレッドがあります。この値を増やすと、システムのパフォーマンスが向上します。ConnectionsとThreads_createdの状態変数を比較することで、この変数の効果を確認できます。
設定ルールは次のとおりです。1GBは8、2GBは16、3GBは32、4GB以上のメモリを大きく設定できます。このクライアントを処理するサーバーのスレッドは、破棄されるのではなく、次のクライアントに応答するためにキャッシュされます（キャッシュの数が上限に達していない場合）
MySQLへの接続を試行した接続の数（接続が成功したかどうかに関係なく）
Threads_cached：現在スレッドキャッシュにあるアイドル状態のスレッドの数を表します。
Threads_connected：現在確立されている接続の数を表します。接続には1つのスレッドが必要なため、現在使用されているスレッドの数と見なすこともできます。
Threads_created：最後のサービス起動以降に作成されたスレッドの数を表します。Threads_created値が大きすぎることが判明した場合は、MySQLサーバーがスレッドを作成していることを意味します。これもリソースを大量に消費します。適切に増やすことができます。構成ファイルのthread_cache_size値。
Threads_running：現在アクティブな（スリープしていない）スレッドの数を表します。使用中のスレッド数を意味するものではありません。接続は確立されている場合もありますが、接続はスリープ状態です。
InnoDBのいくつかの変数を構成します
1.innodb_buffer_pool_size
innodb_buffer_pool_size InnoDBテーブルの場合、innodb_buffer_pool_sizeは、MyISAMテーブルのkey_buffer_sizeと同じ効果があります。InnoDBはこのパラメーターを使用して、データとインデックスをバッファリングするためのメモリのサイズを指定します。単一のMySQLデータベースサーバーの場合、最大値は物理メモリの80％に設定できます。MySQLのマニュアルによると、2Gメモリを搭載したマシンの場合、推奨値は1G（50％）です。データ量が大きくなく、急激に増加しない場合は、innodb_buffer_pool_sizeを大きく設定する必要はありません。
mysql> show variables like 'innodb_buffer_pool_size';
+-------------------------+-----------+
| Variable_name | Value |
+-------------------------+-----------+
| innodb_buffer_pool_size | 134217728 |
+-------------------------+-----------+
1 row in set (0.00 sec)
// innodb_buffer_pool_sizeを設定し
て/etc/my.cnfファイルを変更し、[mysqld]の下に次のコンテンツを追加します
[root@mysqld01 ~]# tail -1 /etc/my.cnf
innodb_buffer_pool_size = 2048M
2.
innodb_flush_log_at_trx_commit innodb_flush_log_at_trx_commitは主に、innodbがログバッファー内のデータをログファイルに書き込み、ディスクをフラッシュする時点を制御します。値はそれぞれ0、1、および2です。
0は、トランザクションがコミットされたときにログ書き込み操作は実行されないが、ログバッファ内のデータは毎秒ログファイルに書き込まれ、ディスクがフラッシュされることを意味します。1の場合、毎秒またはすべてのトランザクションコミットはログファイルの書き込みとディスクのフラッシュを行う操作により、トランザクションのACIDが保証されます。2に設定すると、トランザクションがコミットされるたびにログファイルへの書き込みが発生しますが、ディスクのフラッシュ操作は1秒ごとに完了します。実際のテストでは、この値がデータの挿入速度に大きな影響を与えることがわかりました.2に設定すると、10000レコードを挿入するのに2秒しかかからず、0に設定すると、1秒しかかかりません。 1に設定すると、229秒かかります。したがって、MySQLマニュアルでは、挿入操作を可能な限り1つのトランザクションに組み合わせることも推奨しています。これにより、速度が大幅に向上する可能性があります。MySQLのマニュアルによると、この値は、最新のトランザクションを失うリスクを許容することを前提として、0または2に設定できます。
3. innodb_thread_concurrency
innodb_thread_concurrency = 0このパラメーターは、同時innodbスレッドの数を設定するために使用されます。デフォルト値の0は、制限がないことを意味します。設定する場合は、サーバーのCPUコアの数と同じか2回です。 cpuのコア数。デフォルト設定をお勧めします。通常は8です。
mysql> show variables like 'innodb_thread_concurrency';
+---------------------------+-------+
| Variable_name | Value |
+---------------------------+-------+
| innodb_thread_concurrency | 0 |
+---------------------------+-------+
1 row in set (0.00 sec)
mysql> set GLOBAL innodb_thread_concurrency=8;
Query OK, 0 rows affected (0.00 sec)
mysql> show variables like 'innodb_thread_concurrency';
+---------------------------+-------+
| Variable_name | Value |
+---------------------------+-------+
| innodb_thread_concurrency | 8 |
+---------------------------+-------+
1 row in set (0.01 sec)
4.
innodb_log_buffer_size innodb_log_buffer_sizeこのパラメーターは、Mを単位として、一部のログファイルで使用されるメモリサイズを決定します。バッファを大きくするとパフォーマンスが向上し、トランザクションが大きくなると、キャッシュサイズを増やすことができます。innodb_log_buffer_size = 32M
5. innodb_log_file_size
innodb_log_file_size = 50Mこのパラメーターは、データログファイルのサイズを決定します。Mでは、設定を大きくするとパフォーマンスが向上します。
7. innodb_log_files_in_group
innodb_log_files_in_group = 3パフォーマンスを向上させるために、MySQLはログファイルを複数のファイルに循環的に書き込むことができます。推奨設定は3です
8. read_buffer_size
read_buffer_size = 1MMySql読み取りバッファーサイズ。テーブルのシーケンシャルスキャンのリクエストは読み取りバッファを割り当て、MySqlはそれにメモリバッファを割り当てます。テーブルの順次スキャン要求が非常に頻繁であり、頻繁なスキャンが遅すぎると思われる場合は、この変数の値とメモリバッファーのサイズを増やすことで、パフォーマンスを向上させることができます。sort_buffer_sizeと同様に、このパラメーターに対応する割り当てられたメモリーも各接続専用です。
9. read_rnd_buffer_size
read_rnd_buffer_size = 16M MySqlランダム読み取り（クエリ操作）バッファーサイズ。行が任意の順序（たとえば、ソート順）で読み取られると、ランダムな読み取りバッファーが割り当てられます。ソートおよびクエリを実行する場合、MySqlは最初にバッファをスキャンしてディスク検索を回避し、クエリ速度を向上させます。大量のデータをソートする必要がある場合は、値を適切に増やすことができます。ただし、MySqlはクライアント接続ごとにこのバッファスペースを発行するため、この値は、過度のメモリオーバーヘッドを回避するために、可能な限り適切に設定する必要があります。注：順次読み取りとは、インデックスのリーフノードデータに従って、必要な行データを順次読み取ることができることを意味します。ランダム読み取りとは、セカンダリインデックスリーフノードのプライマリキーに従って実際の行データを見つける一般的な必要性を指し、セカンダリインデックスとプライマリキーは異なるデータセグメントに配置されるため、アクセス方法はランダムです。
10. bulk_insert_buffer_size
bulk_insert_buffer_size = 64M、デフォルトでは8M効果的に挿入効率を向上させることができるデータ・バッファ・サイズ、インサートバッチであります
11.バイナリログ
log-bin = / usr / local / mysql / data / mysql-bin binlog_cache_size = 2M //各セッションに割り当てられたメモリは、トランザクション中にバイナリログのキャッシュを保存し、レコードビンを改善するために使用されます-ログの効率。大きなトランザクションはありません。dmlの頻度が低い場合は、小さく設定できます。トランザクションが大きくて多く、dml操作が頻繁な場合は、大きな値に調整できます。前者の提案は–1M、後者の提案は次のとおりです。2–4M max_binlog_cache_size = 8M // binlogが使用できる最大キャッシュメモリサイズを示しますmax_binlog_size = 512M //現在のログサイズがに達した場合、binlogログファイルのサイズを指定しますmax_binlog_size、そして新しいバイナリログが自動的に作成されます。この変数を1GBより大きくまたは4096バイトより小さく設定することはできません。デフォルト値は1GBです。大容量のSQLファイルをインポートする場合は、sql_log_binを閉じることをお勧めします。そうしないと、ハードディスクがそれを保持できず、定期的に削除することをお勧めします。expire_logs_days = 7 // mysqlが期限切れのログをクリアする時間を定義します。バイナリログが自動的に削除される日数。デフォルト値は0で、「自動削除なし」を意味します。mysqladmin flush-logsは、新しいバイナリログを再起動することもできます。
12.log_queries_not_using_indexes
log_queries_not_using_indexesこのオプションをオンにすると、すべての行を返すクエリが実際に記録されます。
最適化前後の比較
//最適化の前
[root@mysqld01 ~]# mysqlslap --defaults-file=/etc/my.cnf --concurrency=10 --iterations=1 --create-schema='test1' --query='select * from test1.tb1' --engine=innodb --number-of-queries=2000 -uroot -p123.com –verbose
mysqlslap: [Warning] Using a password on the command line interface can be insecure.
Benchmark
Running for engine innodb
Average number of seconds to run all queries: 0.101 seconds
Minimum number of seconds to run all queries: 0.101 seconds
Maximum number of seconds to run all queries: 0.101 seconds
Number of clients running queries: 10
Average number of queries per client: 200
//最適化
[root@mysqld01 ~]# mysqlslap --defaults-file=/etc/my.cnf --concurrency=10 --iterations=1 --create-schema='test1' --query='select * from test1.tb1' --engine=innodb --number-of-queries=2000 -uroot -p123.com –verbose
mysqlslap: [Warning] Using a password on the command line interface can be insecure.
Benchmark
Running for engine innodb
Average number of seconds to run all queries: 0.039 seconds
Minimum number of seconds to run all queries: 0.039 seconds
Maximum number of seconds to run all queries: 0.039 seconds
Number of clients running queries: 10
Average number of queries per client: 200
//パラメータを最適化する
[root@mysqld01 ~]# cat /etc/my.cnf
[mysqld]
basedir = /usr/local/mysql
datadir = /usr/local/mysql/data
port = 3306
server_id = 1
socket = /usr/local/mysql/mysql.sock
log-error = /usr/local/mysql/data/mysqld.err
pid-file = /usr/local/mysql/data/mysql.pid
slow_query_log = 1
slow_query_log_file = /usr/local/mysql/data/slow-query.log
long_query_time = 1
log-queries-not-using-indexes
max_connections = 1024
back_log = 128
wait_timeout = 60
interactive_timeout = 7200
key_buffer_size=256M
query_cache_size = 256M
query_cache_type=1
query_cache_limit=50M
max_connect_errors=20
sort_buffer_size = 2M
max_allowed_packet=32M
join_buffer_size=2M
thread_cache_size=200
innodb_buffer_pool_size = 2048M
innodb_flush_log_at_trx_commit = 1
innodb_log_buffer_size=32M
innodb_log_file_size=128M
innodb_log_files_in_group=3
log-bin=mysql-bin
binlog_cache_size=2M
max_binlog_cache_size=8M
max_binlog_size=512M
expire_logs_days=7
read_buffer_size=1M
read_rnd_buffer_size=16M
bulk_insert_buffer_size=64M
log-error = /usr/local/mysql/data/mysqld.err