MySQLの遅いクエリ問題の詳細な分析データ送信

例を通して、MySQL のデータ テーブル送信のクエリが遅い問題の解決策を共有しました。

最近、コードの最適化中に、SQL ステートメントが非常に遅いことがわかったので、さまざまな方法を使用して調査し、ようやく原因を見つけました。

1. 事故現場

og.goods_barcode、og.color_id、og.size_id、SUM(og.goods_number) AS sold_number FROM order o を選択 
LEFT JOIN order_goods og ON o.order_id = og.order_id WHERE o.is_send = 0 AND o.shipping_status = 0 
AND o.create_time > '2017-10-10 00:00:00' AND o.ck_id = 1 AND og.goods_id = 13421 AND o.is_separate = 1 AND o.order_status IN (0, 1) AND og.is_separate = 1 
og.color_id、og.size_id でグループ化

上記のステートメントは、結合テーブル グループ化クエリ ステートメントです。

実行結果:

このステートメントには1.300秒かかり、 Sending dataは1.28秒かかり、時間のほぼ 99% を占めていることがわかります。そのため、これを最適化します。

どのように最適化するのでしょうか?

2. SQL文の分析のための3つのコツ

1. 分析を説明する

上記の文explain 。

説明 SELECT og.goods_barcode, og.color_id, og.size_id, SUM(og.goods_number) AS sold_number FROM order o 
LEFT JOIN order_goods og ON o.order_id = og.order_id WHERE o.is_send = 0 AND o.shipping_status = 0 
AND o.create_time > '2017-10-10 00:00:00' AND o.ck_id = 1 AND og.goods_id = 13421 AND o.is_separate = 1 AND o.order_status IN (0, 1) AND og.is_separate = 1 
og.color_id、og.size_id でグループ化

実行結果:

explainを通じて、上記のステートメントがインデックスkeyを使用していることがわかります。

2. プロセスリストを表示する

説明しても問題は明らかにならないので、何が遅いのでしょうか?

そこで、 show processlistを使用して SQL ステートメントの実行ステータスを表示することを考えました。クエリ結果は次のとおりです。

クエリが長時間「データ送信中」状態であったことが判明しました。

「データ送信中」ステータスの意味を調べてください。このステータスの名前は非常に誤解を招くものであることがわかります。いわゆる「データ送信中」は単にデータを送信するのではなく、「データの収集 + 送信」が含まれます。

ここで重要なのは、なぜデータを収集する必要があるかということです。その理由は、MySQL が「インデックス」を使用してクエリを完了した後、MySQL が一連の行 ID を取得するためです。一部の列がインデックスにない場合、MySQL は「データ行」に戻って返されるデータを読み取り、クライアントに返す必要があります。

3. プロフィールを表示

クエリの時間分布をさらに検証するには、 show profileコマンドを使用して詳細な時間分布を表示します。

まず設定を開きます: set profiling=on;

クエリを実行した後、show profiles を使用してクエリ ID を表示します。

詳細情報を表示するには、クエリ query_id の show profile を使用します。

3. トラブルシューティングと最適化

1. 確認して比較する

上記の手順を実行すると、クエリが遅いのは、データ送信ステータスに多くの時間が費やされているためであることが判明しました。データ送信の定義と組み合わせて、ターゲットはクエリ ステートメントの戻り列に焦点が当てられます。

一つずつ確認した後、最終的に説明欄に配置することにしました。この欄のデザインは、 description varchar(8000) DEFAULT NULL COMMENT 'ゲームの説明'、

そこで、私たちは「説明を返さない結果」がどのようになるかを見るために比較アプローチを採用しました。ショープロフィールの結果は以下のとおりです。

【解決】

問題の根本原因が見つかれば、解決は難しくありません。いくつかの方法があります:

1) 検索時に説明クエリを削除しますが、これはビジネスの実装によって制限され、ビジネスに大きな調整が必要になる場合があります。

2) テーブル構造を最適化し、記述を別のテーブルに分割します。これは大きな変更であり、既存のビジネスが変更に協力する必要があります。ビジネスが引き続きこの記述の情報のクエリを実行する必要がある場合、最適化後のパフォーマンスは大幅に向上しません。