MySQLサービスのパラメータの最適化

MySQL サービスのパラメータはすべて、my.cnf または my.ini ファイルの [mysqld] グループ内にあります。構成後、MySQL サービスを再起動して有効にします。

1. パフォーマンスに比較的大きな影響を与えるいくつかのパラメータ:

  1. innodb_buffer_pool_size:
    InnoDB タイプのテーブルとインデックスの最大キャッシュ。最も重要なパラメータの 1 つで、デフォルトのサイズは 128M です。
    インデックス データだけでなく、テーブル データもキャッシュします。値が大きいほど、クエリが高速になります。ただし、この値が大きすぎると、オペレーティング システムのパフォーマンスに影響します。
  2. key_buffer_size:
    インデックスバッファのサイズ。インデックス バッファはすべてのスレッドで共有されます。
    これにより、インデックス処理の速度、特にインデックス読み取りの速度が決まります。もちろん、この値はできるだけ大きくなく、そのサイズはメモリのサイズによって異なります。この値が大きすぎると、オペレーティング システムが頻繁にページを変更し、システムのパフォーマンスが低下します。
    約 4GB のメモリを備えたサーバーの場合、このパラメータは 256M または 384M に設定できます。
    key_buffer_size は MyISAM テーブルに対してのみ機能します。MyISAM テーブルを使用しない場合でも、この値を使用しますが、内部一時ディスク テーブルは MyISAM テーブルです。
  3. table_cache:
    キャッシュされたテーブルの最大数を制限するために使用されます。現在キャッシュされているテーブルが table_cache に達しない場合、新しいテーブルが追加されます。この値に達した場合、MySQL は最後のクエリ時間とクエリ レートに従ってテーブルを解放します。キャッシュされたテーブルの前のキャッシュ。
    値が大きいほど、同時に開くことができるテーブルの数が増えます。物理メモリが大きいほど、設定も大きくなります。デフォルトは 2402 ですが、512 ~ 1024 に調整するのが最善です。同時に開かれるテーブルが多すぎるとオペレーティング システムのパフォーマンスに影響を与えるため、この値はできるだけ大きくしません。
  4. query_cache_size:
    クエリ バッファのサイズを示します。
    Qcache_lowmem_prunes の値が非常に大きい場合は、バッファが不足していることが多いため、Query_cache_size の値を増やす必要があることを示し、Qcache_hits の値が非常に大きい場合は、
    クエリ バッファが非常に頻繁に使用されていることを示します。小さいと効率に影響するため、クエリ キャッシュを使用しないことを検討できます。
  5. query_cache_type:
    キャッシュのタイプを制御するために使用されます。この値は気軽に設定できず、数値に設定する必要があることに注意してください。
    query_cache_type=0 (OFF) の場合、すべてのクエリはクエリ キャッシュを使用しません。ただし、query_cache_type=0 を指定しても、MySQL は query_cache_size で設定されたバッファ メモリを解放しません。
    query_cache_type=1 (ON) の場合、クエリ ステートメントで SQL_NO_CACHE が指定されていない限り、すべてのクエリでクエリ キャッシュが使用されます (例: SELECT SQL_NO_CACHE * FROM tbl_name; query_cache_type=2 (DENAND) の場合、クエリ ステートメントの SQL_CACHE キーワードでのみ使用されます
    )の場合、クエリはクエリ キャッシュを使用します。クエリ キャッシュを使用すると、クエリの速度が向上します。これは、変更操作がほとんどなく、同じクエリ操作が頻繁に実行される状況にのみ適しています。
  6. sort_buffer_size:
    sort_buffer_size は接続レベルのパラメータであり、各接続が初めてこのバッファを使用する必要があるときに、設定されたメモリが一度に割り当てられます。
    ソートが必要な各スレッドによって割り当てられるバッファのサイズを示します。このパラメータの値を増やすと、ORDER BY または GROUP BY 操作の速度が向上します。デフォルト値は 2 097 144 バイト (約 2MB) です。
    約 4GB のメモリを備えたサーバーの場合、推奨設定は 6 ~ 8M です。接続数が 100 の場合、実際に割り当てられる合計ソート バッファ サイズは 100x6 = 600MB です。
  7. join_buffer_size:
    結合クエリ操作で使用できるバッファのサイズを示します。システムのデフォルト サイズは 512k、Mac のデフォルト サイズは 256k、sort_buffer_size- と同様、このパラメータに対応する割り当てメモリは次のとおりです。また、各接続に排他的です。
  8. read_buffer_size:
    MySQL 読み取りバッファのサイズです。テーブルを順次スキャンするスレッドが読み取りバッファを割り当てます。MySQL はそれにメモリ バッファを割り当てます。read_buffer_size 変数は、このバッファのサイズを制御します。テーブルテーブル
    の順次スキャンが非常に頻繁に行われ、頻繁なスキャンが遅すぎると思われる場合は、この変数の値とメモリ バッファのサイズを増やすことでパフォーマンスを向上させることができます。read_buffer_size 変数はこれを制御して改善します。テーブルの順次スキャンの効率。
    SET SESSION read_buffer_size=n は、このパラメータの値を一時的に設定できます。デフォルトは 64K ですが、4M に設定できます。
  9. innodb_flush_log_at_trx_commit :
    バッファ内のデータがいつログ ファイルに書き込まれ、ログ ファイルがディスクに書き込まれるかを示します。このパラメータは innoDB エンジンにとって非常に重要です。トランザクションをコミットする場合、特定の戦略に従って、REDO ログが REDO ログ バッファからディスク ファイルにフラッシュされます。現時点では、この戦略は innodb_flush_log_at_trx_commit を通じて構成されます。このパラメータには 0、1、2 の 3 つの値があります。このパラメータのデフォルト値は 1 です。
    値 0: トランザクションをコミットするとき、REDO ログ バッファ内のデータはすぐにディスク ファイルにフラッシュされませんが、InnoDB のメイン スレッドを使用して 1 秒ごとにディスクが更新されます。この時点でトランザクションを送信すると、mysql がダウンし、この時点でメモリ内のすべてのデータが失われます。
    値 1: トランザクションをコミットするときは、REDO ログをメモリからディスク ファイルにフラッシュする必要があります。トランザクションが正常にコミットされている限り、REDO ログはディスク上に存在する必要があります。オペレーティング システムの「遅延書き込み」機能により、この時点のフラッシュはオペレーティング システムのバッファにのみ書き込まれるため、同期操作によりハード ディスクに確実に保持されることに注意してください。
    値 2: トランザクションをコミットするとき、ディスク ファイルに直接入力するのではなく、ディスク ファイルに対応する OS キャッシュに REDO ログを書き込みます。OS キャッシュのデータがディスク ファイルに書き込まれるまでに 1 秒かかる場合があります。
    実際にトランザクションの耐久性を保証できるのは 1 だけであることがわかりますが、リフレッシュ操作 fsync() がブロックされ、完了するまで戻らないため、ディスクへの書き込み速度が非常に遅いことがわかります。 MySQL のパフォーマンスが大幅に低下します。トランザクションの損失を気にしない場合は、0 と 2 の方が高いパフォーマンスを実現できます。
  10. innodb_log_buffer_size:
    これは、InnoDB ストレージ エンジンのトランザクション ログによって使用されるバッファです。パフォーマンスを向上させるために、情報は最初に Innodb ログ バッファにも書き込まれます。innodb_flush_log_trx_commit パラメータで設定された対応する条件が満たされると (またはログ バッファがいっぱいになると)、ログはファイルに書き込まれます (またはログ バッファに同期されます)。ディスク)。
    バッファーが十分に大きくない場合、複数の IO 書き込みが発生し、キャッシュ内のデータがディスクにフラッシュされます。
  11. max_connections:
    MySQL データベースに許可される接続の最大数を示します。デフォルト値は 151 です。
    サーバーに多数の同時接続リクエストがある場合、この値を増やして並列接続の数を増やすことをお勧めします。もちろん、これはマシンのサポートに基づいています。接続数が増加すると、MySQL はバッファはより多くのメモリを消費するため、値を適切に調整する必要があり、値をむやみに増やすことはできません。
    ステータス変数 connection_errors_max_connections がゼロではなく、増加し続ける場合は、データベース接続数が最大許容値に達したために失敗する接続リクエストが継続して存在することを意味するため、max_connections の値を増やすことを検討できます。Linux プラットフォームでは、性能の良いサーバーであれば 500 ~ 1000 の接続をサポートすることは難しくありませんが、サーバーの性能に応じて評価し、設定する必要があります。これらの接続はメモリ リソースを浪費するため、接続数はできるだけ多くしないでください。接続が多すぎると、MySQL サーバーがフリーズする可能性があります。
  12. back_log :
    back_log は、MySQL が一時的に新しいリクエストへの応答を停止するまでの短期間にスタックに保存できるリクエストの数を示します。
    MySql 接続の数が max_connections に達すると、新しいリクエストはスタックに保存され、接続がリソースを解放するのを待ちます。スタックの数は back_log です。待機している接続の数が back_log を超えると、接続リソースは付与されません。エラーが報告されます。
    バージョン 5.6.6 より前のデフォルト値は 50 で、それ以降のバージョンのデフォルトは 50+(max_connections / 5) です。Linux システムの場合は、512 未満の整数に設定することをお勧めしますが、最大値は 900 を超えません。 。データベースが短期間に大量の接続要求を処理する必要がある場合は、back_log の値を適切に増やすことを検討できます。

2. 簡単な最適化

専用サーバーはメモリの 70% 以上に設定できますが、個人的には innodb_buffer_pool_size をシステム メモリの 50% に設定することをお勧めします。

最適な設定は次のとおりです: innodb_buffer_pool_size=innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances。

それ以外の場合、innodb_buffer_pool_size 自動チューニングは innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances の 2 倍になる可能性があります。

# innodb缓冲池大小
innodb_buffer_pool_size=1G
 
# innodb缓冲池块大小
innodb_buffer_pool_chunk_size=128M
 
# innodb缓冲池实例数
innodb_buffer_pool_instances=8

3. クエリキャッシュヒット率

show variables like 'innodb_buffer_pool%';
  1. Innodb_buffer_pool_read_requests: 論理読み取りリクエストの数。
  2. Innodb_buffer_pool_reads: InnoDB がバッファ プールから満たすことができないため、ディスクから直接読み取る必要がある論理読み取りの数。

パーセント = innodb_buffer_pool_read_requests / (innodb_buffer_pool_reads + innodb_buffer_pool_read_requests) * 100%
上記のパーセント>=99% の場合、現在のバッファ プールが現在の要件を満たしていることを意味します。それ以外の場合は、innodb_buffer_pool_size の値を増やすことを検討してください。

おすすめ

転載: blog.csdn.net/qgbihc/article/details/131301413
おすすめ