この記事の内容は、MySQL データベースの最適化に関する紹介 (写真とテキスト) です。一定の参考価値があります。必要な友人が参照できます。お役に立てれば幸いです。
データベースの最適化は、システムのボトルネックを特定し、MySQL データベース全体のパフォーマンスを向上させることを目的とする一方で、ユーザーの応答速度を向上させるためには、合理的な構造設計とパラメーターの調整が必要です。同時に、システムがより大きな負荷を提供できるように、システム リソースをできる限り節約します (関連する推奨事項: MySQL チュートリアル)
1. 最適化の概要
2. 最適化
著者は、最適化をソフト最適化とハード最適化の 2 つのカテゴリに分類しており、ソフト最適化には一般にデータベースの操作が含まれ、ハード最適化にはサーバー ハードウェアの操作が含まれます。
2.1 ソフト最適化
2.1.1 クエリ ステートメントの最適化
1. まず、EXPLAIN または DESCRIBE (略称: DESC) コマンドを使用して分析できます。クエリ文の実行情報。
2. 例:
DESC SELECT * FROM `user`
Display:
インデックスや
2.1.2 サブクエリの最適化
MySQL では、サブクエリの代わりに JOIN を使用してみてください。サブクエリにはネストされたクエリが必要であるため、一時テーブルが作成されます。クエリをネストするときに作成されます。一時テーブルの作成と削除にはシステムのオーバーヘッドが大きく、結合クエリでは一時テーブルが作成されないため、ネストされたサブクエリよりも効率が高くなります。
2.1.3 インデックスの使用
インデックスによりデータベース クエリの速度が向上します。最も重要な方法の 1 つです。インデックスについては、著者の記事「MySQL データベース インデックス」を参照してください。導入についてはさらに詳しく説明されています。インデックスを使用する際の 3 つの主要な注意事項がここに記録されています:
テーブルの分析: ANALYZE TABLE user などの ANALYZE キーワードを使用します;
Op: 実行された操作を示します
Msg_type: 情報の種類 (ステータス、情報など) 、メモ、警告、エラー##LOCAL|NO_WRITE_TO_BINLOG はすべて、ログに書き込まないことを意味します。テーブルの最適化は VARCHAR に対してのみ行われ、BLOB および TEXT が有効です。ファイルの断片化は OPTIMIZE TABLE ステートメントによって排除でき、読み取り専用ロックが追加されます
2.2 ハード最適化
2.2.1 ハードウェア3点セット
1. マルチコアかつ高周波数のCPUを構成します。
2. 大きなメモリを構成し、メモリを増やしてキャッシュ容量を増やすと、ディスク I/O 時間が短縮され、応答速度が向上します。
3. 高パフォーマンスのメモリを構成します。高速ディスクまたは合理的に分散されたディスク: 高速ディスクは I/O を向上させ、分散ディスクは並列操作の能力を向上させることができます。
2.2.2 データベース パラメータの最適化
データベース パラメータを最適化すると、並列処理の能力が向上します。リソース使用率が向上し、MySQL サーバーのパフォーマンスが向上します。MySQL サービスの構成パラメータはすべて my.cnf または my.ini にあります。パフォーマンスに大きな影響を与えるパラメータは以下にリストされています。
key_buffer_size: インデックス バッファsize
table_cache: 同時に開くことができるテーブルの数
query_cache_size と query_cache_type: 前者はクエリ バッファ サイズ、後者は前のパラメータのスイッチです。0 はバッファを使用しないことを意味し、1 はバッファを使用することを意味しますが、クエリ内で SQL_NO_CACHE を使用して意味を表すことができます。バッファを使用しないことを意味します。2 は、クエリ内で明確に指定されている場合、つまり SQL_CACHE にのみバッファを使用する必要があることを意味します。
sort_buffer_size: 並べ替えバッファ
Portal:続きパラメータ
2.2.3 サブデータベースとサブテーブル
##データベースの負荷が高すぎるため、最初の問題は、ピーク時にシステムのパフォーマンスが低下する可能性があることです。過度のデータベース負荷はパフォーマンスに影響を与えます。もう 1 つは、過度の圧力によりデータベースがクラッシュした場合はどうすればよいでしょうか?したがって、この時点では、システムをデータベースとテーブルに分割し、読み取りと書き込みを分離する、つまり、1 つのデータベースを複数のデータベースに分割し、複数のデータベース サービスにデプロイする必要があります。このとき、データベースはメイン データベースとして機能します。書き込みリクエストを処理します。次に、各マスター ライブラリが少なくとも 1 つのスレーブ ライブラリをマウントし、スレーブ ライブラリが読み取り要求を処理します。 2.2.4 キャッシュ クラスターユーザーの数がますます増えている場合は、この時点でマシンを追加し続けることができます。たとえば、システム レベル。マシンを追加すると、より多くの同時リクエストを処理できます。その後、データベース レベルでの書き込み同時実行性がますます高くなると、データベース サーバーが拡張され、サブデータベースとテーブルのシャーディングによってマシンが拡張され、データベース レベルでの読み取り同時実行性がますます高くなると、容量が増加します。拡張され、さらにスレーブ データベースが追加されます。しかし、ここには大きな問題があります。データベース自体は、実際には大量の同時リクエストを処理するために使用されていないため、一般的に言えば、1 台のデータベース マシンが実行する同時実行数は 1 秒あたり数千のオーダーであり、データベースで使用されるマシンは比較的高構成で比較的高価なマシンでは、コストが非常に高くなります。単純にマシンを追加し続けるのは実際には間違っています。したがって、キャッシュは通常、高同時実行性のアーキテクチャに組み込まれており、キャッシュ システムは高い同時実行性を実現するように設計されています。したがって、1 台のマシンが実行する同時実行の量は 1 秒あたり数万、場合によっては数十万に達し、高同時実行の実行能力はデータベース システムの実行能力よりも 1 ~ 2 桁高くなります。したがって、書き込みが少なく読み取りが多いリクエストに対して、システムのビジネス特性に応じてキャッシュ クラスターを完全に導入できます。具体的には、データベースに書き込むときに、データのコピーが同時にキャッシュ クラスターに書き込まれ、キャッシュ クラスターが読み取りリクエストのほとんどを処理するために使用されます。この場合、キャッシュ クラスタリングを通じて、より少ないマシン リソースを使用して、より高い同時実行性をホストできます。#結論
完全で複雑な高同時実行システム アーキテクチャには、さまざまな複雑な自己開発インフラストラクチャ システムが必ず含まれます。あらゆる種類の絶妙なアーキテクチャ デザイン。したがって、小さな記事が他の人にインスピレーションを与える効果をもたらすことはせいぜいですが、データベース最適化のアイデアについてはそれだけです。
以上がMySQL データベース最適化の概要 (写真とテキスト)の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。