私は最近、mysqlのパフォーマンスの最適化を研究し、オンラインでいくつかの知識を学び、それを要約して共有しました。
このトピックは4つの記事を書くことを計画しており、現在最初の部分を提供しています。
全体の概要は以下のとおりです。
最初の記事が最初に書かれています：パフォーマンスに影響を与える要因
1.パフォーマンスに影響を与える要因：
1.1不当な要求：
要件：フォーラム内の投稿の総数の統計
追加要件：リアルタイムの更新
1.初期段階：SELECT COUNT（*）
2。新しいテーブルを作成し、このテーブルの要約データを更新します（頻度の問題）
3。本当の問題は、リアルタイムですか？統計テーブルを作成し、一定期間ごとに1回統計を作成して保存します
。1.2役に立たない関数の蓄積：
1.役に立たない列の蓄積;
2。間違ったテーブルデザイン;
3。役に立たないテーブルの関連付け;
2.1データベースに配置するのに適していないデータ：
1.バイナリデータ;（クエリの効率が低下し、IOの数が増加します）
2.フローキューデータ;（テキストファイルに書き込まれたログと同様）
3.特大のテキスト;
2.2妥当なキャッシュ、どのデータがキャッシュに入れるのに適していますか？
1.システム構成情報。
2.アクティブユーザーの基本情報;（セッションキャッシュ、redisキャッシュ）
3.アクティブユーザーのカスタマイズされた情報。
4.期間に基づく統計データ。
5.読み取り>>>書き込みデータ;
2.3データベースの相互作用を減らす：
N + 1問題の解決策：N + 1問題とは何ですか。オブジェクトには関連するオブジェクトがあり、関連するオブジェクトの関連する属性をオブジェクトのリストに表示する必要があります。1つのSQLを使用してオブジェクトのコンテンツを検索し、N個のSQLを使用して関連するオブジェクトを検索します。
解決：
1.リンククエリを使用します;（結合すると大きな結果セットが返されます。関連付けられたフィールドを冗長フィールドとしてテーブルに配置します。欠点は、関連付けられた更新操作が増えることです）
2. 1 + 1クエリを使用します;（2つのSQLを使用して解決し、Java側でデータフィールドを設定するため、関連付ける必要はありません。この方法をお勧めします）
2.4データベースSQLステートメントの機能への過度の依存：
共通：クロス集計クエリ、不要なテーブル結合クエリ、
大きなSQLを分割し、SQL分割を実行し、数回クエリを実行し、Java側でアセンブルしてマージします。
2.5同じSQLの繰り返し実行。
2.6その他の一般的なシステムアーキテクチャと実装の問題：
1.キャッシュシステムを不当に使用すると、キャッシュヒット率が低くなり、データベースアクセスが増加すると同時に、キャッシュシステムのハードウェアリソースへの投資が無駄になります。
2.オブジェクト指向の考え方への過度の依存とシステムのスケーラビリティの過渡的な追求は、システムが離散的すぎるように設計されている場合にオブジェクトの分解を促進し、システム内に多数の複雑な結合ステートメントをもたらします。MySQLサーバーの主な利点さまざまなデータベースシステムでは、単純な論理クエリの処理もそのロックメカニズムに関連しています。
4.データベースへの過度の依存、データベース内のファイルシステムへの保存により適した大量のデータの保存、データベースリソースの浪費を引き起こし、さまざまなログ情報などのシステムの全体的なパフォーマンスに影響を与えます。
5.過度に理想化されたシステムのユーザーエクスペリエンスにより、リアルタイムの統計計算を実行するためにリアルタイムで更新する必要のない大量のデータなど、多数の非中核企業が大量のリソースを消費します。 。
3.1 SQLによって引き起こされるパフォーマンスの問題の原因：
SQL実行プロセス。
1.クライアントはサーバーにクエリを送信します。
2.サーバーは最初にクエリキャッシュをチェックし、キャッシュにヒットすると、キャッシュに保存されている結果をすぐに返します。それ以外の場合は、次の段階に入ります。
3.サーバー側はSQLの分析と前処理を実行し、オプティマイザーはSQLに関連するデータテーブルの統計情報に従って計算し、対応する実行プランを生成します。
4. MySQLはストレージエンジンのAPIを呼び出して、オプティマイザによって生成された実行プランに従ってクエリを実行します。
5.結果をクライアントに返します。
ディスクIO
SQL実行の最大のボトルネックは、ディスクIO、つまりデータの読み取りにあります。SQLの書き込み方法が異なると、実行プランも異なり、実行プランが異なれば、IOの桁もまったく異なり、パフォーマンスが低下します。
3.2スキーマ（テーブル構造）設計がシステムパフォーマンスに与える影響：
1.冗長データの処理。適切なデータ冗長性により、クエリ全体のパフォーマンスを向上させることができます。補足：データベースの3つのパラダイム
第一正規形（1NF）は、リレーショナルモデルの基本要件です。第一正規形（1NF）を満たさないデータベースは、リレーショナルデータベースではありません。つまり、データベーステーブルの各列は分離できない基本データ項目です。 、および同じ列に存在することはできません。複数の値
2番目の正規形（2NF）では、データベーステーブルの各インスタンスまたは行を一意に区別できる必要があります。
3番目の正規形（3NF）では、データベーステーブルに、他のテーブルにすでに含まれている非主キー情報が含まれていない必要があります。（冗長データは許可されません）
2.大きなテーブルは小さなテーブルに分割され、ビッグデータのある列は別々に小さなテーブルに分割されます。
1.データベースでは、属性が多すぎるテーブルは一般に設計されていません。
2.データベースには、通常、5/10百万を超えるデータを含むテーブルはありません（テーブルの分割、ロジックによる分割、ビジネスによる分割）。
3.ビッグデータのある列は、小さなテーブル（リッチテキストエディター、CKeditor）に分割されます。
3.必要な表示に従って、より合理的なテーブル構造を設定します。
4.共通の属性を小さなテーブルに分割します。
1.共通属性を照会するために照会する必要がある列を減らします。
2、一般的に使用される属性の集中キャッシュを容易にします。
3.3パフォーマンスに対するハードウェア環境の影響：
1.IOインジケーターを改善する
IOPS：1秒あたりに提供できるIOアクセスの数。
IOスループット：1秒あたりの合計IOトラフィック。
2.CPUの計算能力を向上させます。
3.別のデータベースサーバーの場合は、ネットワーク容量を改善します。
3.4データベースシステムのシナリオ：
2つの典型的なデータベースアプリケーションシナリオ：
①オンライントランザクション処理OLTP（オンライントランザクション処理）：OLTPは、主に銀行取引などの基本的および日常的なトランザクション処理のための、従来のリレーショナルデータベースの主なアプリケーションです。
②オンライン分析処理（OLAP）：OLAPは、データウェアハウスシステムのメインアプリケーションです。複雑な分析操作をサポートし、意思決定支援に重点を置き、直感的で理解しやすいクエリ結果を提供します。データウェアハウスは典型的なアプリケーションシナリオです。
OLTPデータベースアプリケーションの特性：
1.システム全体のデータ量は多いが、活動データ量は少ない。
2. IOアクセスは頻繁であり、関連するデータの量は少なく、分散は離散的です。
3.高い同時実行性。
4.ネットワーク相互作用データの量は少ないですが、相互作用は頻繁です。
OLTPシステムハードウェアアーキテクチャの選択：
1.妥当なキャッシュ設計が多数あると、データベースの相互作用を大幅に減らすことができます。メモリ容量を可能な限り拡張する必要があります。
2.より高いIOPSインデックス要件。
3. CPUの計算能力、および並列計算能力の要件が高い。
4.外部ネットワークに対するより高い要件。
OLAP機能：
1.データの量が非常に多く、データアクセスが集中しており、データアクティビティが均等に分散されています。
2.同時アクセスが少ない、
3.検索の数は毎回非常に多くなります。
OLAPアーキテクチャの選択：
1.ハードディスクのストレージ容量は非常に大きくする必要があります。
2.ストレージデバイスのIOスループットに対する非常に高い要件。
3.CPU要件を低くします。
4.外部ネットワークの要件は高くありません。
4包括的な検討
要件とアーキテクチャおよびビジネス実現要件は、既存の基準に基づいて最適化されています：55％
実際、私たちができることは次のとおりです。1。SQLステートメントクエリの最適化は約30％を占めます。2。サーバーデータベースハードウェアの改善は約15％を占めます。