オラクル - 大量のデータを持つテーブルの複数のカウントに関するアドバイスが必要

Question

大きなデータを持つテーブル、誰もカウントステートメントを最適化する方法を知っていますか？

例：テーブル予約（id、email、mobile、....）（約30フィールド）。

Function GetBookingCount(p_email, p_mobile) return number 
    Select count(id) 
    from Booking 
    Where email = p_email 
    or mobile = p_mobile 

Function GetBookingStatus3Count(p_email, p_mobile) return number 
    Select count(id) 
    from Booking 
    Where (email = p_email or mobile = p_mobile) 
    and status = 3; 

最終選択：

Select GetBookingCount(email, mobile) as BookingCount 
     , GetBookingStatus3Count(email, mobile) as BookingStatus3Count 
     , ... 
From Booking 
where .... 

解決法1：どのような句は、電子メールのカラム、移動、ステータス列としてカウントする場所でのフィールド列のインデックスを設定します。

解決策2：カウントする列が少ない新しい表を作成します。 新しいテーブル：Booking_Stats（ID、電子メール、モバイル、ステータス）。

ありがとうございます。

Answer 1

予約テーブルには、電子メール、モバイル、ステータスに関するインデックスが必要です。あなたはこの選択を使用する必要があります。

WITH B1 AS 
(
    SELECT ID, 
      COUNT(ID) CNT1, 
      STATUS 
    FROM BOOKING 
    WHERE EMAIL = P_EMAIL 
      AND MOBILE = P_MOBILE 
) 
SELECT CNT1, 
     COUNT(ID) CNT2 
FROM B1 
WHERE STATUS = 3; 

Answer 2

select count(*) count_all, count(case when status=3 then 1 else null end) count_status_3 
from Booking 
where email = p_email and mobile = p_mobile 

//注：クエリが頭から書かれている、あなたが（電子メール、携帯電話）や（Eメール、モバイルにインデックスを作成することを検討します

をテストしていません、ステータス）を取得し、ステータス変更のためのインデックスの更新コスト（許可されている場合）を支払うことになります。同じ行のステータスが多数更新されている場合は、インデックス作成のみ（電子メール、モバイル）[読み込み/書き込みコストのトレードオフ]をお勧めします。

電子メールは非常に判別できます（1つの値でほとんどの列が除外されます）。そうでない場合は、モバイル列がより適切な候補である場合は、（モバイル、電子メール）に注文を変更することを検討してください。

Answer 3

GetBookingBlahBlah()の機能は役に立たず、実際には性能に害を及ぼします。

ことが確実であることは困難ですのであなたは、要件の完全なセットを投稿していないが、これらの線に沿って解決策をより遂行的であろうと思わ（...が何を意味するのか？）：

with bk as (
    select * 
    from booking 
    where email = p_email 
    or mobile = p_mobile 
) 
select count(*) as BookingCount 
     , count(case when bk.status = 3 then 1 end) as BookingStatus3Count 
     , ... 
from bk 

基本テーブルを一度に照会し、すべてのカウントを計算するために必要なすべてのデータを取得し、可能な限り小さな結果セットで集計をクランチすることが考えられます。

booking(email,mobile)のインデックスは役に立つかもしれませんが、おそらくそうではありません。より良い解決策は、p_emailとp_mobileのそれぞれに対して異なるクエリを持ち、各クエリをサポートする単一の列インデックスを使用することです。