1

これは私が書いた SQL クエリです。正常に動作しますが、遅いです。

SELECT D.Username, 
        SUM(CASE WHEN D.type = 'Yes' THEN 1 ELSE 0 END) as Yes, 
        SUM(CASE WHEN D.type = 'No' THEN 1 ELSE 0 END) as No, 
        SUM(CASE WHEN D.type = '' THEN 1 ELSE 0 END) as Other, 
        SUM(CASE WHEN S.mobile IS NULL THEN 0 ELSE 1 END) as Sales, 
        COUNT(*) as TOTAL FROM dairy as D
  LEFT JOIN (SELECT DISTINCT mobile FROM sales) as S on D.MobileNo = S.mobile 
        WHERE source = 'Network' AND UNIX_TIMESTAMP(CheckDate) >= 1309474800 AND UNIX_TIMESTAMP(CheckDate) <= 1309561200
 group by D.Username order by TOTAL DESC

ご覧のとおり、はい、いいえ、その他、および一致する MobileNo ( D.MobileNo = S.mobile) 販売の数をカウントします。

タイプ、ユーザー名、モバイル、MobileNO、CheckDate、およびソースにインデックスを追加しようとしましたが、パフォーマンスはあまり向上しませんでした。

4

2 に答える 2

2

クエリで注意すべき 3 つのポイント:

1. 「LEFT JOIN」がパフォーマンスの問題を引き起こしている可能性があります。

D.MobileNoただし、に存在しない値が存在する可能性があるため、必要ですSELECT DISTINCT mobile FROM sales。他の回避策 (オプションがあります) を使用すると、パフォーマンスが低下する可能性が高くなります。しかし、次の項目を観察することでパフォーマンスが向上する可能性があります。

2. キー列にインデックスがあることを確認します。

  • D型
  • S.mobile
  • D.Mobileいいえ
  • D.ユーザー名
  • D.ソース
  • D.CheckDate

3. 「UNIX_TIMESTAMP(CheckDate)」によるフィルタリングに問題がある可能性があります

これが重要な問題かもしれません。特に に大量のレコードがある場合は、UNIX_TIMESTAMP(CheckDate)ではなく でフィルタリングすると問題が発生する可能性があります。問題は、 のインデックスがあっても、関数のためにおそらく使用されないことです。単独でフィルタリングしてみてください。CheckDateDairyCheckDateCheckDate

于 2011-07-28T13:38:22.463 に答える
0

これがタイム クリティカルな場合は、より多くのデータを保存することも理にかなっています。

ここでは、YesValue、NoValue、OtherValue の INT 列を追加し、アプリケーションで 0 または 1 を入力することを意味します。これを行うことで、SELECT 部分から大文字と小文字の計算を削除できます。

また、現在利用可能なすべてのインデックスを投稿してください。コメントには、テーブルの CREATE ステートメントが記載されています。

于 2011-07-28T13:37:15.990 に答える