MySQL の SQLパフォーマンス テストが遅い原因の概要:
01. クエリされたテーブルにはインデックスが作成されていません
クエリ SQL を作成しましたが、クエリ条件フィールドにインデックスがなかったため、データを見つけるためにテーブル全体をスキャンする必要がありました。これは誰もが最も遭遇することであり、最も理解しやすいものでもあります。
一般に、テーブルのデータ量が 100,000 レベル未満など、比較的少ない場合は遅く感じませんが、テーブルのデータ量が 100,000 レベル以上になると、クエリ時間が特に長くなります。長さ。
02. クエリのインデックスが無効です
インデックスを知ることは非常に重要なので、テーブルを構築する際には通常、インデックスを追加しますが、インデックスが正しく使用できるかどうかにも依存するため、インデックスがあるからといってクエリの速度が速くなるわけではありません。
無効なインデックスの一般的な原因は次のとおりです。
クエリ条件、インデックスフィールドなし
クエリ条件で or および選択的なフィルタリング条件が使用されているため、インデックスが無効になります。
クエリ条件にlikeを使用しているため、先頭からあいまい一致となるため、インデックスが無効になります。
クエリ条件が複合インデックスの左端の一致原則を満たしていないため、インデックスが無効になります。
クエリ条件、インデックス列で暗黙的な型変換が使用されるため、インデックスが無効になります
クエリ条件、インデックス列が集計関数を使用しているため、インデックスが無効になります
クエリ条件、インデックス列で算術演算 (+、-、...) が使用されているため、インデックスが無効になります。
クエリ条件、インデックス列で論理演算 (!=、<>、null である、null ではない...) が使用されているため、インデックスが無効になります。
左と右が関連付けられている場合、フィールドの型が一致しないため、インデックスが無効になります。
03. クエリは一時テーブルを使用します
一時テーブルについてはご存じないかもしれませんが、テーブル クエリについては聞いたことがあるかもしれません。テーブル クエリについては、1 つのクエリが満たされない場合、結果を得るために再度、または 2 回チェックする必要があり、当然時間がかかります。
一時テーブルは通常どのように生成されるのでしょうか? クエリによって返されたデータを次の手順でフィルタリングして表示すると、返されたデータがフィルタ条件を満たしていない、または表示するフィールドがないことがわかります。条件を満たすデータを取得するには、元のテーブルを再度確認する必要があります。元のテーブルの条件。これらのデータは一時テーブルに配置されます。本来であれば、一度チェックし直すだけでも時間の無駄ですが、一時テーブルには容量制限があり、メモリ容量を占有するため、すべてのデータを保存できる容量が不足する場合があります。したがって、一般に、一時テーブルが使用されている限り、この SQL のパフォーマンスは非常に低くなります。
04.結合またはサブクエリが多すぎる
実際の業務では関連クエリは非常に頻繁に発生するもので、関連するテーブルが多ければ多いほどデータのフィルタリングが複雑になり、必然的に時間がかかります。したがって、一般的には、関連するテーブルを 3 つ以上持つことはお勧めできません。データ量の少ないテーブルは左側に配置し、大きなテーブルは右側に配置する必要があります。
05. クエリ結果のデータ量が多すぎる
クエリ結果のデータ量が大きすぎる場合は、一般的に 2 つのタイプがあり、1 つ目は、直接チェックされたテーブルのデータ量が大きすぎる (数千万など) ことです。テーブルのサイズは数千万で、インデックスを構築したとしてもインデックスファイルは非常に大きく、深さも非常に深いため、当然クエリ速度は非常に遅くなります。2 番目のタイプは、ジョイント テーブルのデカルト積が大きすぎることです。
最初のタイプの場合、最適化の提案は通常、テーブルにテーブル パーティション化を使用することです。2 番目のタイプは、単純かつ粗雑な SQL 分割最適化です。
06. ロック大会
現在、MySQL テーブルは一般に InnoDB ストレージ エンジンであり、このエンジンのテーブルは行ロックを使用し、一度に 1 行をロックします。つまり、トランザクションが特定のデータ行を操作している場合、この行の操作動作はロックされ、前のトランザクション操作が完了してデータ変更がコミットされるまで他のトランザクションは操作できなくなり、後続のトランザクションはその操作を取得できるようになります。 。これにより、トランザクションは変更を加えますが終了せず、後続のトランザクション操作はすべて待機する必要があります。この時点で複数のトランザクションが並んで待機しており、現在のトランザクション操作が終了すると、待機中のトランザクションがロックをめぐって競合します。このような「あなたは不親切、私は不公平」という状況が発生すると、SQL のパフォーマンスが非常に遅くなります。
07. ページングの制限、深すぎます
特定のデータを取得するために特定の量のデータをオフセットする必要がある場合、limit を使用することを考えるのが簡単ですが、オフセットが大きい場合、オフセットのせいで SQL の実行が非常に遅くなることがわかります。データはページ単位でバッファプールに読み込まれます。データ量が多い場合、占有されるバッファプール領域も大きくなります。この領域のサイズは設定されており、通常はそれほど大きくないため、SQL が遅くなります。
この問題を最適化するには、フィルター条件を作成し、それを制限と組み合わせて実装することをお勧めします。
08. 設定パラメータが無理がある
私たちはデータベースをよく使用しますが、データベース構成パラメータをあまり理解して設定する必要がなく、インストール後すぐに使用します。この記事では、データベースの非常に重要な設定パラメータである buff について何度も言及しましたが、mysql には、buff、cache、size、length、max、min、limit などの単語を含む多くのパラメータがあります。は非常に重要な構成パラメータです。これらの構成パラメータは、データベースのパフォーマンスに直接関係します。データベースが高度な構成のマシンにインストールされているが、これらの構成パラメーターを変更する方法がわからない場合は、デフォルト値を使用してください。「これだけハードウェア構成が優れているのに、なぜパフォーマンスがこんなに悪いのか？」と嘆くばかりです。
09. 汚れたページを頻繁にブラッシングする
ダーティ ページは、一貫性のないメモリ データ ページとディスク データ ページです。これは通常、データ更新操作中に発生します。データを更新するには、まずデータを読み取り、メモリ内で更新し、ログ ファイルを生成し、ログ ファイルを再生してテーブル データを更新する必要があります。更新データ量が多い場合、バッファプールがいっぱいの場合、またはその後に生成される再生ログファイルがいっぱいの場合、動作処理が遅くなります。
この種の問題を最適化するには、小さなバッチで変更して複数回送信することが一般的に推奨されます。
10. システムリソースが十分ではありません
データを保存するデータベースは頻繁にディスク操作を行う必要があるため、通常はディスク IO パフォーマンスの高いマシンをデータベース サーバーとして選択します。同時に、データベースは頻繁にデータを交換する必要があるため、十分なメモリも必要となり、それに応じてメモリ要件も高くなります。これらのハードウェアは、データベース サーバーのハードウェアを選択するための基本要件にすぎません。データベースもソフトウェアであり、ソフトウェアはオペレーティング システムにもインストールされるため、オペレーティング システムのパラメーターにもいくつかの制限がかかります。 、ハードウェア リソースが十分でない場合、またはシステム パラメーターの制限値に達した場合も、動作が遅くなります。