Чому кілька разів швидше, ніж один СУМ з CASE?

Мені хотілося знати, який із наступних двох підходів швидше:

1) три 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) SUMз FROM-клаузою:

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;

Мене здивувало, що різниця така велика. Перший запит із трьома підзапросами повертає результат негайно, тоді як другий SUMпідхід потребує 18 секунд.

Claimsце подання, яке вибирається з таблиці, що містить ~ 18 мільйонів рядків. На стовпчику FK в ClaimStatusтаблиці є індекс, який містить ім'я статусу.

Чому це має велику різницю, використовую COUNTчи SUM?

Плани виконання:

• COUNT
• SUM

Всього 12 статусів. Ці три статуси належать 7% усіх рядків.

Це фактичний вигляд, я не впевнений, чи це актуально:

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 

COUNT(*)Версія може просто шукати в індекс у вас на колонці статусу один раз для кожного стану , ви вибираєте, в той час як SUM(...)потреби версії для стягнуть індексувати дванадцять разів (загальна кількість унікальних статусів).

Очевидно, що шукати індекс три рази, буде швидше, ніж шукати 12 разів.

Перший план вимагає надання пам'яті в розмірі 238 МБ, тоді як другий план вимагає надання пам'яті в 650 МБ. Це може бути , що велика субсидія пам'ять не може бути негайно заповнений, роблячи запит , який набагато повільніше.

Змініть другий запит таким чином:

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';

Це дозволить оптимізатору запитів усунути 75% прагнень до індексу, і це повинно призвести як до меншої необхідності надання пам'яті, меншим вимогам вводу / виводу, так і до швидшого часу до результату.

SUM(CASE WHEN ...)Конструкція по суті запобігає оптимізатор запитів від розсовуючи Statusпредикати вниз в індекс шукати частина плану.