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

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

藏色散人

リリース： 2021-02-07 14:57:28

転載

2938 人が閲覧しました

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 つの写真を見てみましょう

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

Pagoda パネルを使用して簡単な MySQL パフォーマンスチューニングを実現する方法 ##明らかに、(図 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 サイトの他の関連記事を参照してください。