MySQL Performance Blogのかなり古い記事を無料で翻訳したもので、mySQLの基本バージョンをインストールした後、すぐに設定する方が良いとされています。
サーバーにmySQLをインストールし、デフォルト設定のままにしておく人がどれだけいるかは驚くべきことです。
変更できるmySQLの設定は非常に多くありますが、実際に非常に重要な特性のセットがあり、独自のサーバー用に最適化する必要があります。 通常、このような小さなセットアップの後、サーバーのパフォーマンスは著しく向上します。
- key_buffer_sizeは、MyISAMテーブルを使用する場合に非常に重要な設定です。 MyISAMのみを使用する場合は、使用可能なRAMの約30〜40%に設定します。 正しいサイズは、インデックス、データ、およびサーバー負荷のサイズに依存します-MyISAMはオペレーティングシステム(OS)キャッシュを使用してデータを保存するため、データ用にRAMに十分なスペースを残す必要があり、データはインデックスよりもはるかに多くのスペースを占有することに注意してください ただし、 key_buffer_sizeディレクティブによってキャッシュに割り当てられたスペース全体が常に使用されていることを確認してください-すべての.MYIファイルの合計サイズが1 GBを超えていないにもかかわらず、インデックスキャッシュに4 GBが割り当てられている状況をよく見ることができます。 これを行うことは完全に役に立たないので、リソースを費やすだけです。 MyISAMテーブルが実質的にない場合は、 key_buffer_sizeを約16〜32 MBに設定する必要があります。ディスク上のメモリに作成された一時テーブルのインデックスを保存するために使用されます。
- innodb_buffer_pool_sizeも同様に重要な設定ですが、InnoDBの場合、主にInnoDBテーブルを使用する場合は注意してください。 これらは、MyISAMテーブルよりもバッファサイズに対して非常に敏感です。 原則として、MyISAMテーブルは、大量のデータと標準のkey_buffer_size値でも正常に機能しますが、 innodb_buffer_pool_size値が正しくない場合、mySQLは大幅に「遅く」なります。 InnoDBはバッファーを使用してインデックスとデータの両方を保存するため、OSキャッシュ用のメモリーを残す必要はありません-innodb_buffer_pool_sizeを利用可能なRAMの70-80%に設定します(もちろん、InnoDBテーブルのみが使用される場合を除きます)。 key_buffer_sizeと同様に、このオプションの最大サイズに関しては、気にしないでください。最適なサイズを見つけ、利用可能なメモリを最大限に活用する必要があります。
- innodb_additional_mem_pool_size-このオプションはmySQLのパフォーマンスにほとんど影響しませんが、InnoDBにさまざまな内部ニーズのために約20 MB(またはそれ以上)を残すことをお勧めします。
- innodb_log_file_sizeは、特に大容量の場合、テーブルへの書き込み操作が頻繁に行われるデータベース環境で非常に重要な設定です。 サイズを大きくするとパフォーマンスは向上しますが、注意してください-データ回復時間も長くなります。 通常、サーバーのサイズに応じて、値を約64〜512 MBに設定します。
- innodb_log_buffer_size-このオプションの標準値は、平均数の書き込み操作と小さなトランザクションを持つほとんどのシステムに非常に適しています。 システムにアクティビティのバーストがある場合、またはBLOBデータを積極的に使用している場合は、 innodb_log_buffer_sizeの値をわずかに増やすことをお勧めします。 ただし、無理をしないでください。値が大きすぎるとメモリが無駄になります。バッファは毎秒フラッシュされるため、この秒の間に必要以上のスペースは必要ありません。 推奨値は約8〜16 MBで、データベースが小さい場合はさらに小さくなります。
- innodb_flush_log_at_trx_commit -InnoDBの実行がMyISAMの100倍遅いことを訴えますか? おそらくinnodb_flush_log_at_trx_commitの設定を忘れていました 。 デフォルト値の「1」は、各UPDATEトランザクション(またはトランザクション外の同様のコマンド)がバッファーをディスクにフラッシュする必要があることを意味します。これは非常にリソースを消費します。 ほとんどのアプリケーション、特に以前にMyISAMテーブルを使用していたアプリケーションは、値「2」でうまく動作します(つまり、「バッファをディスクにフラッシュせず、OSキャッシュにのみフラッシュします」)。 ただし、ログは1〜2秒ごとにディスクにフラッシュされるため、事故が発生した場合、最大1〜2秒の更新が失われます。 値を「0」にするとパフォーマンスは向上しますが、mySQLサーバーがクラッシュしてもデータを失うリスクがあります。innodb_flush_log_at_trx_commitを「2」に設定すると、オペレーティングシステム全体がクラッシュした場合にのみデータが失われます。
- table_cache-テーブルを開くと、かなりのリソースが消費されます。 たとえば、MyISAMテーブルは.MYIファイルのヘッダーを「現在使用中」としてマークします。 通常、テーブルを頻繁に開くことはお勧めしません。したがって、キャッシュはすべてのテーブルを開いたままにするのに十分な大きさであることが最善です。 これには、一定量のOSリソースとRAMが使用されますが、これは通常、最新のサーバーにとって重大な問題ではありません。 数百のテーブルがある場合、 table_cacheオプションの開始値は「1024」になる可能性があります(各接続には独自の記述子が必要なことに注意してください )。 さらに多くのテーブルまたは多くの接続がある場合-パラメーターの値を増やします。 table_cache値が100,000のmySQLサーバーを見ました。
- thread_cache-スレッドの作成/破棄は、接続が確立され、すべての接続が切断されるたびに発生するリソース集約型の操作でもあります。 通常、このオプションを16に設定します。アプリケーションで同時接続数が急増し、 Threads_Created変数がスレッド数の急激な増加を示す場合は 、 thread_cache値を増やします。 目標は、サーバーの通常の機能で新しいスレッドが作成されるのを防ぐことです。
- query_cache_size-アプリケーションが多くのデータを頻繁に読み取り、アプリケーションレベルでキャッシュがない場合、このオプションは非常に役立ちます。 大きな要求キャッシュを処理すること自体が高価になるため、ここではあまり重要視しないでください。 推奨値は32〜512 MBです。 クエリキャッシュの使用状況を確認することを忘れないでください-条件によっては(キャッシュ内のヒット数が少ない場合、つまり同じデータが実際に選択されていない場合)、大きなキャッシュを使用するとパフォーマンスが低下する場合があります。
ご覧のとおり、これらはグローバル設定です。 これらの変数は、サーバーのハードウェアと使用されるmySQLエンジンに依存しますが、通常、セッション変数は特定のタスク専用に構成されます。 主に単純なクエリを使用する場合、64 GBのRAMが余分にある場合でも、
sort_buffer_sizeの値を増やす必要はありません。 さらに、大きなキャッシュ値はサーバーのパフォーマンスを低下させるだけです。 セッション変数は、後でサーバーを微調整するために残しておくのが最適です。
PS:mySQLのインストールには、さまざまな負荷向けに設計されたいくつかのプリインストールされたmy.cnfファイルが付属しています。 サーバーを手動で構成する時間がない場合は、通常、サーバーの負荷により適したものを選択して、標準構成ファイルよりもサーバーを使用することをお勧めします。