何かが起こってもパニックにならず、まず記録してください: 遅いクエリの最適化における mysql

この記事では、mysql のクエリ最適化が遅いという問題について説明します。SQL を分析し、チェックし、最適化する方法を段階的に説明します。一緒に見てみましょう。皆さんのお役に立てれば幸いです。

mysql のクエリの最適化が遅かったことを思い出してください。本番環境の To-Do リストのライブ デモンストレーションでは、結果; 突然、製品 マネージャーは、長年の経験を持つ上級開発者として、もう我慢できずに考えました、そして彼の顔は笑いでいっぱいでした。

ただし、アリーナでの長年の経験があるため、何かが起こってもパニックにならず、まず写真を撮ってください。

推奨学習: 「MySQL ビデオ チュートリアル 」

最初のステップは SQL を分析することです

 ***from event i 
 left join project p on i.project_id = p.project_code 
 left join dict d on i.type_id = d.id 
 left join record re on re.incident_id = i.id
 left join type it on it.id = i.type_id 
 where i.version_flag = 0 and i.flow_id in (大量条件)***复制代码

When flow_id in access条件が多数あると、SQL の速度が直接低下し、以前の 80 ミリ秒から 5.8 秒に低下します。また、ここには関連テーブルが多数あります。

2 番目のステップは、インデックスを確認して Explain を実行することです

インデックスを確認して、re.incident_id と i.flow_id にインデックスが作成されていないことが判明した場合、とてもうれしいです。問題が見つかりました。わかりました。インデックスを作成します。しかし、SQL を実行すると、卵がないことがわかりました。私は賢いので、Explain を直接開いたところ、レコードの種類が all であり、インデックスがないことがわかりました。

なぜ?なぜ?

3 番目のステップは、関連する 2 つのフィールドのフィールド タイプ、長さ、および文字タイプが一致しているかどうかを確認することです

フィールドを比較すると、型とフィールドの長さが完全に一致していることがわかりました。少し落ち込んでいた後、新しい手がかりを見つけました -

イベント テーブルの ID の文字型は次のとおりです:

レコード テーブルの Incident_id の文字タイプは次のとおりです。

## プロジェクト チームとの統一性を維持するために、utf8mb4 を決定的かつ統一的に使用します。 ; もう一度説明しますが、時間は手動でわずか 1 秒です。

4 番目のステップは、インデックス操作の使用を強制することです。

テーブルが

の場合、mysql はデフォルトで全文検索を使用します。インデックス ベースが次の場合は、 が小さすぎるため、テーブルの業務量が大きすぎても、インデックス フィールドが基本的に同じデータまたは null の場合でも、sql に強制インデックスを記述する必要があります。強制インデックス ソリューションを使用してください。 SQL で左結合の後に強制を追加します。index(alarm_id)——

5 番目のステップ、IN は通常インデックス付きです。 IN の後ろのデータが の場合 データテーブル内の一致数が

30% を超える場合、インデックスを使用せずにテーブル全体をスキャンするため、IN がインデックスを使用するかどうかは、データの量に関係します。その後のデータ。 左結合を使用すると、大量のデータを処理できます。

以上が何かが起こってもパニックにならず、まず記録してください: 遅いクエリの最適化における mysqlの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。