MySQLのパフォーマンスチューニング - あなたは15個の変数の重要性を理解しなければなりません
はじめに：
MYSQLのWEBは、最も人気のあるバックエンドデータベースでなければなりません。最近のNOSQLはますます言及されているが、私は信じていますが、ほとんどの建築家はMYSQLのデータストレージを行うことを選択します。著者はMySQLのパフォーマンスチューニングにソート15個の重要な変数をまとめたもので、彼らはまた、兄が言っ願う不十分補完する必要があります。
1.DEFAULT_STORAGE_ENGINE
あなたはすでにMySQLの5.6または5.7を使用していると、あなたのテーブルはInnoDBのであれば、それはあなたが設定されていることを意味します。ない場合は、あなたのテーブルはInnoDBテーブルに変換し、InnoDBテーブルにdefault_storage_engine設定されていることを確認してください。
なぜ？InnoDBは（Percona ServerとMariaDBを含む）MySQLの最高のストレージエンジンであるため、要するに、 - それはトランザクションをサポートし、高い同時実行（正しく構成されている場合）、非常に優れた性能を持っています。ここでは詳細なバージョンが理由を説明しています
2.INNODB_BUFFER_POOL_SIZE
InnoDBは、最も重要な変数です。実際には、メインのストレージエンジンInnoDBの場合、あなたのために、MySQLのこの変数が最も重要です。
実質的に、innodb_buffer_pool_sizeは、MySQL InnoDBのバッファプールに割り当てられるべきであるどのくらいのメモリを指定し、InnoDBのバッファ・キャッシュ・データ、セカンダリインデックス、ダーティデータを格納する（しかし、変更がディスクデータにフラッシュされていない）のためのプールとのような内部構造の種々適応ハッシュインデックス。
経験によると、別のMySQLサーバに総メモリマシンの全体MySQLの80％に割り当てる必要があります。あなたのMySQLは共有サーバー上で実行されている、またはあなたが知りたい場合はInnoDBのバッファプールのサイズが正しく設定され、これを詳しく見てみると。
3.INNODB_LOG_FILE_SIZE
MySQLのコミュニティでファイルの設定をREDOログのInnoDBも、トランザクション・ログと呼ばれています。MySQLの5.6.8 innodb_log_file_size = 5Mのトランザクションログの既定値になるまでのInnoDBのパフォーマンスの最大の単一キラーです。MySQLの5.6.8以降では、デフォルト値は48Mにアップグレードするが、はるかに低い、多くのシステムのために少し忙しいです。
経験によると、サーバーがビジー状態のときに、ログのサイズは1〜2時間に蓄積されたエネルギーの量に書き込むことができます設定する必要があります。あなたはあまりにも多くのトラブルをしたくない場合は、あなたが良好な性能を持つようになる1-2G性能のサイズを設定します。この変数は、詳しくはこちらを参照して、も重要です。
次の変数に入る前に、のはinnodb_log_buffer_sizeについて簡単な言及を見てみましょう。「クイックリファレンス」理解することはしばしば困難としばしば過大な注意ですので。実際には、ほとんどの場合、あなただけの小さなバッファを必要とする - あなたが取引で十分に小さいトランザクションの変更を保存する前にコミットし、ハードディスクに書き込まれます。
もちろん、あなたが大多数のトランザクションを持っている場合は変更、デフォルトのInnoDBのログバッファサイズよりも大きい値は、あなたのパフォーマンスになります変更、ある程度改善されているが、あなたは自動コミットを使用している、またはあなたの取引は、数kよりも少ないを変更それはそれのデフォルト値を維持することでした。
4.INNODB_FLUSH_LOG_AT_TRX_COMMIT
デフォルトでは、すぐに各トランザクションの後に1つのInnoDBリフレッシュに設定innodb_flush_log_at_trx_commitは、ハードディスクにデータを同期コミット。あなたは自動コミットを使用する場合は、あなたのすべてのINSERT、UPDATE、またはDELETEステートメントがコミットし、単一のトランザクションです。
それは、実際の物理ハードディスク同期書き込みを伴うため、同期には、高価な操作（あなたがライトバックキャッシュを持っていない場合は特に）です。だから、可能な場合は、デフォルト値を使用することは推奨されません。
二つの代替値は、0と2のとおりです。
-
（トランザクションがコミットされたときに実際のIO操作）0手段は、同期をハードディスクにフラッシュしないではなく、
- 2は、彼らがいないと述べたとの同期をリフレッシュしません（実際のIO操作）
だから、あなたは0または2に設定した場合、同期動作を1秒に1回行われます。だから、明らかな欠点は、あなたが提出したデータの秒が欠落することができるということです。具体的には、トランザクションが送信されましたが、サーバーはすぐにオフにした後、あなたは実現しなかったと同等のものを提出します。
許容できない銀行などの金融機関、のために、表示します。サーバーがクラッシュした場合でも、最終的には大きな問題が2 |しかし、ほとんどのサイトのために、あなたはinnodb_flush_log_at_trx_commit = 0を設定することはできません。結局のところ、唯一の30代の崩壊は、数年前（つまりmaddeningly遅い修復プロセスに言及していない）とき、多くのサイトがまだデータが失われ、MyISAMテーブルを使用してあります。
だから、0と2それとの間の実際の違いは何ですか？オペレーティング・システムのキャッシュのリフレッシュ動作が非常に高速であるため、大幅なパフォーマンスの違いは、ごくわずかです。だから、明らかにMySQLの（全体ではなく、マシン）の崩壊の場合には、0に設定する必要があり、データがOSのキャッシュにすでにあるので、あなたはすべてのデータを失うことはありません最終的にハードディスクに同期されます。
5.SYNC_BINLOG
sync_binlog書かれた文書の数が多いと、それとのみましょう簡単なアカウントのinnodb_flush_log_at_trx_commitの関係はすでにあります。
サーバーは、サーバーから設定されていない、とあなたがバックアップしていない場合a）には、良好な性能を持っていますsync_binlog = 0を設定します。
b）のサーバーからバックアップを持っているんが、あなたがバイナリログにイベントの一部が欠けて気にしない場合や、より良いパフォーマンスを得るため、プライマリサーバがクラッシュすると、= 0をsync_binlogするとき場合。
C）サーバーからバックアップを持っていて、サーバーからの一貫性について非常に懸念している、と時間能力の特定の時点にデータベースを復元するために、最新の一貫性のあるバックアップとバイナリログを使用して（時点までの時間で復元することができた場合）、その後、あなたはinnodb_flush_log_at_trx_commit = 1、と真剣にsync_binlog = 1を使用することを検討する必要性を設定する必要があります。
問題はsync_binlog = 1のコストが比較的高いことである-今もハードディスクに一度トランザクションごとに同期します。次の2つが1同期、正しい考え方に結合していない理由を考えるかもしれない-のMySQL（5.6および5.7、MariaDBとPerconaサーバ）の新バージョンをコミットマージすることができました、そして、この場合にはsync_binlog = 1つの操作はそうではありません高価な、まだ古いMySQLのバージョンでは、パフォーマンスに大きな影響を与えます。
6.INNODB_FLUSH_METHOD
innodb_flush_methodは、ダブルバッファリングを避けるためにO_DIRECTを設定します。あなたは、オペレーティングシステムがサポートされていないO_DIRECTするときに使用してはならない場合のみを。Linuxを実行している場合でも、直接IOをアクティブにするためにO_DIRECTを使用しています。
InnoDBのバッファプールキャッシュとOSが同時に同じデータを保持しますので - すべてのデータベースの変更は、ハードディスクの前にキャッシュを同期させるために最初のOSに書き込まれているので、直接IOせずに、ダブルバッファリングは、発生します。あなたのプールがその書き込みが集中環境を意味する合計メモリの50％に限定されている場合は特に、あなたはメモリの50％まで無駄かもしれません。制限はおそらく高圧OSサーバーのキャッシュに、50％でない場合は交換するために使用されます。
簡単に言えば、設定innodb_flush_method = O_DIRECT。
7.INNODB_BUFFER_POOL_INSTANCES
MySQLの5.5バッファはスループットを向上させるために内部ロック競合MySQLを低減するための手段の一例として紹介されています。
少しの助けのスループットを向上させるために、このバージョン5.5では、あなたは、MySQL 5.6と設定可能な5.7で控えめにセットinnodb_buffer_pool_instances = 4を、MySQL5.5かもしれないので、アップグレードのMySQLの5.6バージョンでは、非常に大きいです例8-16プール。
あなたが設定した後の観察では、パフォーマンスを向上させるために少しを見つけるだろうが、ほとんどの高負荷条件では、良好な性能を持っている必要があります。
ちなみに、この設定を使用すると、単一のクエリの応答時間を短縮することができます期待しないでください。これは、私は、サーバーの高い同時負荷に見ることができる唯一の違いです。たとえば、同時に複数のスレッドは、物事の多くを行います。
8.INNODB_THREAD_CONCURRENCY
あなたは、多くの場合、0はそれを残していない= innodb_thread_concurrencyを設定する必要が聞こえることがあります。しかし、これは時に低負荷のサーバーのみが正しいです。、システム内のこの時間は、通常のプロセスにクエリをオーバーロードしたい、サーバーのCPUやIOの使用が飽和状態にさらされている場合は特に臨時のピークそして、それは強く注意innodb_thread_concurrencyをお勧めします。
InnoDBは、並列に実行されるスレッドの数を制御する方法がある - 私たちは、同時実行制御メカニズムと呼ばれます。ほとんどがinnodb_thread_concurrency値によって制御されています。0に設定した場合、InnoDBはすぐに（限り）すべての着信要求を処理して、同時実行制御は、閉じられています。
あなたは32CPUコアと4つだけの要求を持っている場合は問題ありません。しかし、単にコアと32 4CPU要求であなたを想像 - あなたは同時に処理32個の要求を行った場合、あなたの悩み。明らかに通常より遅い少なくとも8倍（実際にはより8倍）、次いで非常に可能性があり、自身の外部および内部ロック、これらの要求各要求を蓄積し、これらの32個の要求のみ4 CPUコア、なぜなら。
ここでは、mysqlコマンドラインプロンプトの実行を、この変数を変更する方法は次のとおりです。
グローバルinnodb_thread_concurrency = Xを設定して、
ほとんどのワークロードとサーバーのために、8を設定し、良いスタートです、そしてあなたは、サーバーリソースの使用率に応じて、この制限に達することができ、徐々に不十分な利用が増加します。あなたは、次の行のようになり、クエリ処理のショーエンジンInnoDBのステータスの\ Gを通じて現在の状況を見ることができます：
InnoDBの内部22のクエリ、キュー104個のクエリ
9.SKIP_NAME_RESOLVE
これを追加していない多くの人々が残っているので、この1は、言及されなければなりませんでした。あなたは、接続時にDNS解決を回避するためにskip_name_resolveを追加する必要があります。
DNSサーバは、ほとんどの場合、非常に迅速に解決するため、ほとんどの場合、これは、あなたが何を感じる変更されません。DNSサーバに障害が発生した場合でも、あなたのサーバーが要求のすべてが突然スローダウンし始めている理由である、「認証されていない接続を」と表示されます上に表示されます。
これは、変更前に発生するためにそれほど待つことはありません。今、この変数を追加し、ホストベースの許可名を避けます。
10.INNODB_IO_CAPACITY、INNODB_IO_CAPACITY_MAX
-
innodb_io_capacity：ダーティデータをフラッシュする際に使用される場合、毎秒実行書き込みIOのMySQLの量を制御します。
- innodb_io_capacity_max：ダーティデータをフラッシュするときに、第2のあたりに実行書き込みIOのMySQLの量を制御する圧力の下で
SELECTクエリの実行 - まず、それは読書とは何の関係もありません。読み取り操作のために、MySQLは最大の可能な処理を行い、その結果を返します。書き込み操作については、MySQLはリフレッシュする必要どのくらいのデータをチェックする各サイクルでは、バックグラウンドでリフレッシュサイクルになり、リフレッシュ動作innodb_io_capacity指定された数以上で行うことはありません。これは、（バッファを変更するダーティページの重要な補助記憶装置である前に、彼らがディスクにフラッシュ）バッファマージを変更することを含みます。
MySQLは、バックグラウンドでそれが来て新しい書き込み操作を可能にするためにリフレッシュする必要があるデータの一部を更新する際に第二に、私が何を意味するかを説明する必要があり、MySQLは、「圧力の下で」、「緊急」と呼ばれます。次に、MySQLはinnodb_io_capacity_max使用されます。
だから、あなたはinnodb_io_capacityを設定し、なぜinnodb_io_capacity_max必要がありますか？
最良の方法は、お使いのストレージ設定ランダム書き込みのスループットを測定し、その後、最大IOPSを達成するために、あなたのデバイスを設定innodb_io_capacity_maxすることです。innodb_io_capacityは、お使いのシステムは、主に、書き込み動作の場合は特に、それの50から75パーセントに設定されています。
通常は、IOPSがある、あなたのシステムを予測することができます。RAID10ハードディスクは、例えば、8 15Kから成るが約1000、毎秒ランダム書き込みを行うので、あなたはinnodb_io_capacity = 600とinnodb_io_capacity_max = 1000を設定することができます。多くの低コストのエンタープライズSSDはそうで4,000-10,000 IOPSとを行うことができます。
この値は、毎日の激務完璧少し問題が設定されています。しかし、あなたは時折リフレッシュ処理を取り込むことができるように、デフォルトで、あなたの書き込みスループット200および400を制限することに注意してください。この問題が発生した場合、それはあなたのハードディスクがIOスループットを書きで到達しているか、または値が低すぎる限界スループット設定されています。
11.INNODB_STATS_ON_METADATA
あなたは、MySQL 5.6または5.7を実行している場合、あなたはそれが正しく設定されているように、デフォルト値のinnodb_stats_on_metadataを変更する必要はありません。
しかし、MySQLの5.5または5.1、それは強く、この変数をクローズすることをお勧めします - それは開いている場合は、コマンドshowテーブルのステータスクエリーINFORMATION_SCHEMAとして、すぐにではなく、数秒待って、その後、実行、それは余分なIO操作を使用します。
5.1.32のリリースから、これはあなたがそれを閉じるためにMySQLサーバを再起動する必要はありませんを意味し、動的な変数です。
12.INNODB_BUFFER_POOL_DUMP_AT_SHUTDOWN＆INNODB_BUFFER_POOL_LOAD_AT_STARTUP
Innodb_buffer_pool_dump_at_shutdownとは、これらの二つの変数innodb_buffer_pool_load_at_startupパフォーマンスとは何の関係もありませんが、あなたは時折（たとえば、有効な構成のような）MySQLサーバを再起動した場合、それが関連しています。2が活性化されると、バッファプールのMySQL（具体的には、キャッシュページ）の内容は、停止のMySQLでファイルに保存されています。あなたは次のMySQLを起動すると、それは3-5のウォームアップ時間に速度を上げるために、バッファプールの内容をロードするためにバックグラウンドスレッドを開始します。
二つのこと：
まず、閉じたとき、それは実際にはファイルのバッファプールに内容をコピーしていない、単にページ・テーブル・スペースのIDとIDをコピーする - ディスク上のページを見つけるのに十分な情報を。そして、かなり小さいランダム読み取りの数千人を必要とするよりも、オーダーの多くの非常に高速な読み込み、それらのページを読むことができるようになります。
MySQLはあなたが（どんな効果を持っていないようです）要求の受け付けを開始する前に、バッファプールのコンテンツの読み込みが完了するまで待つ必要がないので、第二に、あなたが起動したときには、バックグラウンドでコンテンツをロードすることです。
innodb_buffer_pool_dump_pct、お薦め75-100を - MySQLの5.7.7から開始し、デフォルトのバッファー・プール・ページのわずか25％がファイルを閉じていますが、この値を制御することができますmysqlの中に格納されています。
この機能は、MySQLの5.6からサポートされています。
13.INNODB_ADAPTIVE_HASH_INDEX_PARTS
あなたは、サーバーのMySQL SELECTクエリの数が多い（と可能な限り最適化されています）、あなたの次のボトルネックでの適応型ハッシュインデックスを実行している場合。アダプティブハッシュインデックスを使用すると、最も一般的なクエリパターンのパフォーマンスを向上させることができ、動的インデックスのInnoDB内部のメンテナンスです。この機能は、シャットダウンし、サーバーを再起動しますが、MySQLのすべてのバージョンではデフォルトでオープンすることができます。
この技術は、非常に複雑であり、ほとんどの場合、その促進効果まで、クエリのほとんどの種類になります。ただし、データベースにあまりにも多くのクエリを持っている場合、ある時点でそれはAHIロックとラッチを待ってあまりにも多くの時間を過ごすことになります。
あなたは、MySQL 5.7であれば、我々はこの問題を持っていない - innodb_adaptive_hash_index_partsのデフォルト設定は8であるので、グローバルミューテックスが存在しないため、適応ハッシュインデックスは、8つのパーティションに切断されます。
しかし、バージョンで前5.7のmysqlに、パーティションのAHI制御の数です。言い換えれば、AHIを保護するために、グローバルミューテックスがあり、多くの場合、壁にぶつかるあなたの選択クエリになることがあります。
だから、あなたが5.1または5.6、および選択クエリを多数実行されている場合、最も簡単な解決策は、AHIのパーティションをアクティブにするためにPercona Serverの同じバージョンに切り替えることです。
14.QUERYCACHETYPE
人々は良いクエリキャッシュの結果と思われる場合は、確かにそれを使用する必要があります。まあ、時にはそれが便利です。しかし、これはあなたが低負荷であるときに、最も特に低負荷時に、読んで少量を書いたりしないことですのみ有用です。
その場合は、query_cache_type = ONとquery_cache_size = 256M十分。しかし、サーバーの原因となるクエリキャッシュは、深刻な一時停止を引き起こすことがあるため、それ以外の場合は失敗します、256Mの高い値を設定しないことを覚えておいてください。
MySQLサーバの高負荷運転した場合、query_cache_size = 0とquery_cache_type = OFFを設定し、有効にするサーバーを再起動することをお勧めします。MySQLのクエリキャッシュのミューテックスとして、すべてのクエリで停止します。
15.TABLE_OPEN_CACHE_INSTANCES
最初からのMySQL 5.6.6は、テーブルキャッシュは、複数のパーティションに分割することができます。
ミューテックスを開いたり、閉じたときに、各テーブルを開いているテーブルの現在のリストを格納するために使用されるテーブルキャッシュがロックされている - それは暗黙的に一時テーブルであったとしても。複数のパーティション絶対還元電位競合を使用してください。
MySQLの5.7.8、table_open_cache_instances = 16から起動すると、デフォルトの設定です。
この記事のように著者は、ああ、毎日のJava関連記事を更新しました信者を覚えておくことがポイント