Pagoda パネルを使用して簡単な MySQL パフォーマンス チューニングを実現する方法

Pagoda パネル の次のチュートリアル コラムでは、Pagoda パネルを通じて MySQL パフォーマンスの簡単なチューニングを実現する方法を紹介します。困っている友人の役に立てば幸いです。

Pagoda パネルを使用した MySQL パフォーマンスの簡単なチューニング

PHP MYSQL アーキテクチャ Web サイトの運用中に、 MySQL、PHP、CPU、ディスク IO、キャッシュなど、さまざまなパフォーマンスの問題が頻繁に発生します。その中でも、MySQL のボトルネックは、Web サイトのパフォーマンスに影響を与える最も一般的で解決が難しい要因です。通常、redis、memcached、およびその他のキャッシュ コンテンツをキャッシュするソフトウェアは確かに最良のソリューションの 1 つですが、Web サイト プログラムのサポートが必要です。ただし、一般的に使用されている Web サイト プログラムのほとんどは、これらのキャッシュ ソフトウェアをサポートしていないか、完全にはサポートできません。今日は MySQL の使用方法について説明します。 MySQL のボトルネックを軽減するために MySQL のパフォーマンスを最適化するための構成調整。

準備:

1. Pagoda Linux パネル正式バージョン 5.2.0 (2017/09/20 リリース) ベータ版 5.2.4

2、MySQL 5.x

通常、MySQL のチューニングは次の部分に分けられます:

1. MySQL 構成パラメータのチューニング (Web サイトの運用に応じて調整する必要があります)

2. データ テーブル インデックスのチューニング (効果は明ら​​かですが、通常、優れたオープン ソース プログラムは調整する必要はありません)

3. SQL ステートメントのチューニング (これはプログラマまたは DBA が行うことです)

今日は主に、Pagoda パネルの新機能を使用して MySQL 構成パラメータを調整する方法について説明します。最初に 2 つの写真を見てみましょう

##明らかに、(図 1) は MySQL の現在の実行ステータスを示し、(図 2) は MySQL の主要な構成パラメータを示します。

これら 2 つの図を解釈してみましょう:

1. アクティブ/ピーク接続の数 (図 1) 現在、アクティブな接続が 1 つあります。MySQL サービスが開始されて以来、最大接続数は 54 です。最大接続数が 54 に近いとき、または(図 2) に等しい場合、max_connections は適切に増やす必要があります。一度に増やしすぎないように注意してください。毎回 50 ずつ増やして、一定期間観察することをお勧めします。十分でない場合は、 、増やし続けます。

2. (図 1) のスレッド キャッシュ ヒット率は 99.78% です。この値が 90% 未満の場合は、(図 2) の thread_cache_size を適切に増やすことをお勧めします。毎回8時までに。

3. インデックスのヒット率 (図 1) インデックスのヒット率は 99.50% です。この値が 95% 未満の場合は、(図 2) の key_buffer_size を適切に増やすことをお勧めします。毎回 64 ずつ増やしてください。説明してください。はい、データベースで Innodb エンジンを使用している場合は、このオプションを無視できます。

4. Innodb インデックスのヒット率 (図 1) Innodb インデックスのヒット率は 100% です。この値が 95% 未満の場合は、適切に使用することをお勧めします (図 2) の innodb_buffer_pool_size を増やします。毎回 64 ずつ増やすことをお勧めします。データベースが Innodb エンジンを使用していない場合は注意してください。 , このオプションは無視して構いません

5. クエリ キャッシュ ヒット率 MySQL クエリ キャッシュは比較対象です。物議を醸す機能ですが、個人的には、redis、memcached などのキャッシュ ソフトウェアを使用している場合は、この機能をオンにすることをお勧めします。 (図 2) で query_cache_size を 0 に設定することでオフにできます。キャッシュ ソフトウェアを使用しておらず、過剰なメモリ使用量がある場合、およびデータベースのボトルネックが明らかな場合は、クエリ キャッシュを有効にすることができます。これはデータに大きく依存する機能です。テーブル構造と SQL ステートメントの最適化: データ テーブル構造と SQL ステートメントがクエリ キャッシュ用に最適化されている場合でも、その効果は非常に優れています。

6. 一時テーブルをディスクに作成する (図 1) 一時テーブルをディスクに作成する割合は 0.42% で、これは、ほとんどの一時テーブルがメモリ内に作成され、ディスク IO オーバーヘッドがあまり増加しないことを示しています。割合が 2% を超える場合は、(図 1) の tmp_cache_size を適切に増やすことをお勧めします。毎回 32 ずつ増やすことをお勧めします。割合が 60% を超える場合は、あきらめてください。一部のオープン ソース プログラムでは、特に最適化された SQL ステートメントではないため、操作中に多数の一時テーブルが開かれ、いくらキャッシュしても十分ではありません。

7. オープン テーブル (図 1) のオープン テーブルが (図 2) の table_open_cache に近いか等しい場合、table_open_cache を適切に増やすことができますが、設定が大きすぎると、プログラムが MySQL 接続を頻繁に中断する場合は、1024 以内にすることをお勧めします。最大値は 2048 を超えないようにしてください。

8. 未使用インデックスの量と未使用の JOIN 量。0 でない場合は、データ テーブルのインデックスを確認します。実際には、1 日あたり数千件ずつ増加するなど、急激に増加しない限り、通常は無視して構いませんが、結局のところ、プログラマや DBA にとってインデックスを最適化する方が適切です。

9. ソート後のマージの数 この値がゆっくり増加している場合は、(図 2) の sort_buffer_size を適切に増やすことをお勧めします。毎回 512 ずつ増やすことをお勧めしますが、最大値は 8192 を超えないようにしてください。この値が急激に増加している場合は、sort_buffer_size を増やしても無駄なので、このオプションを放棄してください。この責任はプログラム開発者に委ねるべきです。

10. テーブル ロックの数 サーバーの CPU オーバーヘッドが低く、テーブルが狂ったようにロックされている場合は、すべてのデータ テーブルを innodb に変換し、変換前に必ずバックアップすることをお勧めします。

11. 最適化計画 メモリサイズに応じた推奨最適化計画であり、基本的な参考値としてのみ推奨し、各設定項目は実際の状況に応じて調整してください。

注: パラメータ設定を保存しても、すぐには有効になりません。忘れずに MySQL サービスを再起動してください。

以上がPagoda パネルを使用して簡単な MySQL パフォーマンス チューニングを実現する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。