最近とても火のMySQL:複雑なアーキテクチャの設計を捨てて、MySQLの最適化の思想は基本的にすべてここにあります

最適化一覧
最適化
筆者は最適化を2つの種類に分けた:ソフト最適化とハード最適化.ソフト最適化は一般的にデータベースを操作すればよい.ハード最適化は、オペレーティングサーバのハードウェアおよびパラメータ設定です.
1、ソフト最適化
1)クエリ文の最適化
まず、EXPLAINコマンドまたはDESCRIBEコマンドを使用して、クエリー文の実行情報を分析できます.
例:

DESC SELECT * FROM `user`

表示:
インデックスやクエリーデータの読み込みデータの数などの情報が表示されます.
2)サブクエリの最適化
MySQLでは、サブクエリの代わりにJOINを使用します.サブクエリにはネストされたクエリが必要なため、ネストされたクエリにはテンポラリ・テーブルが作成され、テンポラリ・テーブルの作成と削除には大きなシステム・オーバーヘッドが発生しますが、接続クエリにはテンポラリ・テーブルは作成されません.したがって、効率はネストされたサブクエリよりも高くなります.
3)索引の使用
インデックスは、データベース・クエリーの速度を向上させる最も重要な方法の1つです.インデックスを使用する3つの注意事項は、次のとおりです.

LIKEキーワードは'%'の先頭の文字列に一致し、インデックスは使用されません.

ORキーワードの2つのフィールドは、インデックスが使用されるインデックスでなければなりません.

複数のカラムインデックスを使用するには、最も左の一致を満たす必要があります.

4)分解表
フィールドが多いテーブルの場合、一部のフィールドが使用頻度が低い場合は、新しいテーブルを形成するために分離する必要があります.
5)中間表
クエリーに大量に接続するテーブルでは、中間テーブルを作成し、クエリー時の接続時間を短縮できます.
6)冗長フィールドの追加
中間テーブルの作成と同様に、冗長性を高めるのも接続クエリーを減らすためです.
7)分析表、検査表、最適化表
分析表は主に分析表中のキーワードの分布である.チェックリストは主にテーブルにエラーがあるかどうかをチェックします.表の最適化は、主に削除や更新による表領域の浪費を解消します.
分析表:ANALYZEキーワード、例えばANALYZE TABLE userを使用する

Op:実行する操作を表す;

Msg_type:status、info、note、warning、errorがある情報タイプ.

Msg_text:情報を表示します.

チェックリスト:CHECKキーワード(CHECK TABLE user[option]など)を使用します.optionはMyISAMにのみ有効です.合計5つのパラメータ値:

QUICK:行をスキャンせず、誤った接続をチェックしない;

FAST:正しく閉じられていないテーブルのみをチェックします.

CHANGED:前回のチェック後に変更されたテーブルと正しく閉じられていないテーブルのみをチェックします.

MEDIUM:削除された接続が有効であることを検証するために行をスキャンします.また、各行のキーワードチェックサムを計算することもできます.

EXTENDED:最も包括的な検査で、各行のキーワードを全面的に検索します.

最適化表:OPTIMIZEキーワード、例えばOPTIMIZE[LOCAL|NO_WRITE_TO_BINLOG]TABLE user;
LOCAL|NO_WRITE_TO_BINLOGはいずれもログに書き込まないことを示しており、最適化テーブルはVARCHAR、BLOB、TEXTにのみ有効であり、OPTIMIZE TABLE文によってファイルの破片を除去し、実行中に読み取り専用ロックを加えることができる.
2、ハード最適化
1)ハードウェア三条件セット

マルチコアと周波数の高いcpuを構成し、マルチコアは複数のスレッドを実行することができる.

は大きいメモリを配置して、メモリを高めて、キャッシュ領域の容量を高めることができて、そのためディスクのI/O時間を減らすことができて、それによって応答速度を高めることができます;

高速ディスクまたは合理的な分散ディスクの構成:高速ディスクはI/Oを向上させ、分散ディスクは並列操作の能力を向上させることができる.

2)データベースパラメータの最適化
データベース・パラメータの最適化により、リソース使用率が向上し、MySQLサーバのパフォーマンスが向上します.MySQLサービスの構成パラメータはすべてmy.cnfかmy.Ini、パフォーマンスに大きな影響を及ぼすいくつかのパラメータを以下に示します.

key_buffer_size:インデックスバッファサイズ;

table_Cache:テーブルを同時に開くことができる個数;

query_cache_sizeとquery_cache_type:前者はクエリーバッファサイズ、後者は前のパラメータのスイッチ、0はバッファを使用しないこと、1はバッファを使用することを示しますが、クエリーでSQL_を使用できます.NO_CACHEはバッファを使用しないことを示し、2はクエリでバッファを使用することを明確に示していることを示します.すなわちSQL_CACHE;

sort_buffer_size:バッファをソートします.

3)分庫表
データベースの圧力が大きすぎるため、まず、データベースの負荷が高すぎるとパフォーマンスに影響を与えるため、ピーク時のシステムのパフォーマンスが低下する可能性があります.
もう一つ、プレッシャーが大きすぎてデータベースを切ったらどうしますか?
そのため、システムをライブラリ分割テーブル+読み書き分離する必要があります.つまり、1つのライブラリを複数のライブラリに分割し、複数のデータベースサービスに配置し、プライマリ・ライブラリとして書き込み要求をロードします.次に、各プライマリ・ライブラリは、少なくとも1つのスレーブ・ライブラリをマウントし、スレーブ・ライブラリによって読み取り要求をロードします.
4)キャッシュクラスタ
ユーザー数がますます大きくなると、システムレベルでマシンを追加し続けることができ、より高い同時要求を運ぶことができます.
その後、データベース・レベルが同時に高くなると、データベース・サーバが拡張され、ライブラリ・テーブルを介して拡張マシンがサポートされ、データベース・レベルの読み取りが同時に高くなると、より多くのスレーブ・ライブラリが拡張されます.
しかし、ここには大きな問題があります.
データベース自体は高同時要求をベアラするために使用されるものではありません.そのため、通常、データベースの単機が毎秒数千桁の並列をベアラしています.また、データベースで使用される機械は比較的高い構成で、比較的高価な機械で、コストが高いです.
もしあなたが簡単に機械を入れ続けているなら、実は間違っています.
そのため、高同時アーキテクチャには通常キャッシュという一環があり、キャッシュシステムの設計は高同時を担うために生まれた.シングルマシンのベアラの同時実行量は、毎秒数万、さらには毎秒数十万であり、高同時実行のベアラ能力はデータベースシステムより1～2桁高い.
システムのビジネス特性に基づいて、その書き込みが少なく、読み取りが多い要求に対して、キャッシュクラスタを導入することができます.
具体的には、データベースを書くときにキャッシュクラスタにデータを同時に書き、キャッシュクラスタでほとんどのリードリクエストをロードします.これにより,クラスタをキャッシュすることで,より少ないマシンリソースでより高い同時負荷を負荷することができる.
締めくくり
完全で複雑な高同時システムアーキテクチャには、さまざまな複雑な自己研究インフラストラクチャシステムとさまざまな優れたアーキテクチャ設計が含まれているに違いない.そのため、小さな文はレンガを投げて玉を引く効果がある.しかし、データベースの最適化の考え方はそれほど悪くない.皆さんに役に立つことを願っています.
転載先:https://blog.51cto.com/13902811/2375603