Tại sao nhiều COUNT nhanh hơn một SUM với CASE?

Tôi muốn biết cách tiếp cận nào trong hai cách sau nhanh hơn:

1) Ba COUNT:

 SELECT Approved = (SELECT COUNT(*) FROM dbo.Claims d
                  WHERE d.Status = 'Approved'),
        Valid    = (SELECT COUNT(*) FROM dbo.Claims d
                    WHERE d.Status = 'Valid'),
        Reject   = (SELECT COUNT(*) FROM dbo.Claims d
                    WHERE d.Status = 'Reject')

2) SUMvới FROM-cách:

SELECT  Approved = SUM(CASE WHEN Status = 'Approved' THEN 1 ELSE 0 END),
        Valid    = SUM(CASE WHEN Status = 'Valid'    THEN 1 ELSE 0 END),
        Reject   = SUM(CASE WHEN Status = 'Reject'   THEN 1 ELSE 0 END)
FROM dbo.Claims c;

Tôi đã ngạc nhiên rằng sự khác biệt là rất lớn. Truy vấn đầu tiên với ba truy vấn con trả về kết quả ngay lập tức trong khi SUMcách tiếp cận thứ hai cần 18 giây.

Claimslà một khung nhìn chọn từ một bảng chứa ~ 18 triệu hàng. Có một chỉ mục trên Cột FK cho ClaimStatusbảng chứa tên trạng thái.

Tại sao nó làm cho một sự khác biệt lớn như vậy cho dù tôi sử dụng COUNThay SUM?

Kế hoạch thực hiện:

• COUNT
• SUM

Có tổng cộng 12 trạng thái. Ba trạng thái này thuộc về 7% của tất cả các hàng.

Đây là chế độ xem thực tế, tôi không chắc nó có liên quan hay không:

CREATE VIEW [dbo].[Claims]
AS
SELECT 
   mu.Marketunitname AS MarketUnit, 
   c.Countryname     AS Country, 
   gsp.Gspname       AS GSP, 
   gsp.Wcmskeynumber AS GspNumber, 
   sl.Slname         AS SL, 
   sl.Wcmskeynumber  AS SlNumber, 
   m.Modelname       AS Model, 
   m.Salesname       AS [Model-Salesname], 
   s.Claimstatusname AS [Status], 
   d.Work_order      AS [Work Order], 
   d.Ssn_number      AS IMEI, 
   d.Ssn_out, 
   Remarks, 
   d.Claimnumber     AS [Claim-Number], 
   d.Rma_number      AS [RMA-Number], 
   dbo.ToShortDateString(d.Received_Date, 1) AS [Received Date], 
   Iddata, 
   Fisl, 
   Fimodel, 
   Ficlaimstatus 
FROM Tabdata AS d 
   INNER JOIN Locsl AS sl 
           ON d.Fisl = sl.Idsl 
   INNER JOIN Locgsp AS gsp 
           ON sl.Figsp = gsp.Idgsp 
   INNER JOIN Loccountry AS c 
           ON gsp.Ficountry = c.Idcountry 
   INNER JOIN Locmarketunit AS mu 
           ON c.Fimarketunit = mu.Idmarketunit 
   INNER JOIN Modmodel AS m 
           ON d.Fimodel = m.Idmodel 
   INNER JOIN Dimclaimstatus AS s 
           ON d.Ficlaimstatus = s.Idclaimstatus 
   INNER JOIN Tdefproducttype 
           ON d.Fiproducttype = Tdefproducttype.Idproducttype 
   LEFT OUTER JOIN Tdefservicelevel 
                ON d.Fimaxservicelevel = Tdefservicelevel.Idservicelevel 
   LEFT OUTER JOIN Tdefactioncode AS ac 
                ON d.Fimaxactioncode = ac.Idactioncode 

Các COUNT(*)phiên bản có thể chỉ đơn giản là tìm kiếm vào chỉ số mà bạn có trong cột trạng thái một lần cho mỗi trạng thái mà bạn đang chọn, trong khi SUM(...)nhu cầu phiên bản để tìm kiếm các chỉ số mười hai lần (tổng số loại trạng thái duy nhất).

Rõ ràng tìm kiếm một chỉ số ba lần sẽ nhanh hơn tìm kiếm 12 lần.

Gói đầu tiên yêu cầu cấp bộ nhớ 238MB, trong khi gói thứ hai yêu cầu cấp bộ nhớ là 650 MB. Có thể là cấp bộ nhớ lớn hơn không thể được điền ngay lập tức, làm cho truy vấn chậm hơn nhiều.

Thay đổi truy vấn thứ hai thành:

SELECT  Approved = SUM(CASE WHEN Status = 'Approved' THEN 1 ELSE 0 END),
        Valid    = SUM(CASE WHEN Status = 'Valid'    THEN 1 ELSE 0 END),
        Reject   = SUM(CASE WHEN Status = 'Reject'   THEN 1 ELSE 0 END)
FROM dbo.Claims c
WHERE c.Status = 'Approved'
    OR c.Status = 'Valid'
    OR c.Status = 'Reject';

Điều này sẽ cho phép trình tối ưu hóa truy vấn loại bỏ 75% tìm kiếm chỉ mục và sẽ dẫn đến cả việc cấp bộ nhớ được yêu cầu thấp hơn, yêu cầu I / O thấp hơn và thời gian kết quả nhanh hơn.

Cấu SUM(CASE WHEN ...)trúc về cơ bản ngăn chặn trình tối ưu hóa truy vấn đẩy các Statusvị từ xuống phần tìm kiếm chỉ mục của kế hoạch.