Query Optimization - Perchè questa velocità la query?

Question

Sto usando ROSPO di Quest for SQL Server in un 2000 Server SQL Server.

Qui è la mia domanda:

SELECT CASE SLCE.GroupName WHEN 'Other' THEN ARM.FBCOMPANY 
                           WHEN 'Inter Co.' THEN ARM.FBCOMPANY 
                           ELSE SLCE.GroupName END AS [Company Name], 
       ARM.fcustno AS [Cust No], 
       ARM.fbcompany AS [Cust Name], 
       ARM.fcinvoice AS [Invoice No], 
       ARM.fdgldate AS [Post Date], 
       year(arm.fdgldate) AS [Year Posted], 
       CASE ARM.fcsource WHEN 'S' THEN 'Shipper' 
                         WHEN 'O' THEN 'Sales Order' 
                         WHEN 'R' THEN 'Receiver' 
                         WHEN 'C' THEN 'Customer' 
                         ELSE ARM.fcsource END AS [Source Doc Type], 
       CASE ARM.fcstatus WHEN 'N' THEN 'New' 
                         WHEN 'U' THEN 'Unpaid' 
                         WHEN 'P' THEN 'Partially Paid' 
                         WHEN 'F' THEN 'Paid in Full' 
                         WHEN 'H' THEN 'Held' 
                         WHEN 'V' THEN 'Voided' 
                         ELSE ARM.fcstatus END AS [Invoice Status], 
       ARM.fpono AS [Cust PO No], 
       ARM.fsalespn AS [Sales Person], 
       ARI.fitem AS [Item No], 
       ARI.fprodcl AS [Prod Class], 
       ARI.fshipkey AS [Qty Invoiced], 
       ARI.ftotprice AS [Net Invoiced], 
       ARI.fpartno AS [Part No], 
       ARI.frev AS [Part Rev], 
       cast(ARI.fmdescript AS VARCHAR(20)) AS [Part Description], 
       ARM.fsono AS [Sales No], 
       ARI.fsokey AS [SO Rels Key], 
       ARI.fordqty AS [Qty Ordered], 
       RED.[YEAR] AS [Year], 
       RED.PERIOD AS [RF Period] 
  FROM dbo.armast ARM 
       INNER JOIN dbo.aritem ARI 
          ON ARM.FCINVOICE = ARI.FCINVOICE 
       INNER JOIN slcdpm SLC 
          ON SLC.fcustno = ARM.fcustno 
       LEFT OUTER JOIN slcdpm_ext SLCE 
         ON SLC.identity_column = SLCE.fkey_id 
       INNER JOIN REDFRIDAYDATES..TBLREDFRIDAYALLDATES RED 
          ON RED.date = CAST (FLOOR (CAST (ARM.fdgldate AS FLOAT)) AS DATETIME) 
 WHERE ARM.fcstatus <> 'V' 
   AND RED.[YEAR] = year(getdate()) 
   AND ari.frev = 'REP' 
   AND ARI.fsalesacc IN ('4010001', '4010002', '4010003', '4010004', '4010005', '4010006', '4010007', '4010008', '4010009', '4010010', '4010018', '4010019', '4010020', '4010021', '4010031', '4010050', '4022000', '4031000', '4045000', '4055000', '4057000', '4060000', '4070000')

Ecco l'opzione di ROSPO (con differenze evidenziato) è:

INNER JOIN dbo.aritem ARI 
          ON ARM.FCINVOICE = ***COALESCE (ARI.FCINVOICE , ARI.FCINVOICE)*** 
       INNER JOIN slcdpm SLC 
          ON SLC.fcustno = ARM.fcustno 
       LEFT OUTER JOIN slcdpm_ext SLCE 
         ON SLC.identity_column = SLCE.fkey_id 
       INNER JOIN REDFRIDAYDATES..TBLREDFRIDAYALLDATES RED 
          ON RED.date = CAST (FLOOR (CAST (ARM.fdgldate AS FLOAT)) AS DATETIME) 
 WHERE ARM.fcstatus <> 'V' 
   AND RED.[YEAR] = year(getdate()) 
   AND ari.frev = 'REP' 
   AND ARI.fsalesacc IN ('4010001', '4010002', '4010003', '4010004', '4010005', '4010006', '4010007', '4010008', '4010009', '4010010', '4010018', '4010019', '4010020', '4010021', '4010031', '4010050', '4022000', '4031000', '4045000', '4055000', '4057000', '4060000', '4070000') 
   ***AND ARI.[fpartno] >= CHAR(0)***

Qualcuno può dirmi perché che si fondono e aggiuntivi e la dichiarazione di accelerare questa query di oltre il 50%?

Answer 1

Hai dato un'occhiata ai piani di esecuzione effettivi. Questi dovrebbero mostrare i diversi approcci che SQL Server ha preso in esecuzione di queste query.

Answer 2

E 'sicuramente uno strano. Il piano di esecuzione dovrebbe dirvi per certo, ma i cambiamenti di prestazioni di questo genere a banche dati venire quasi sempre verso il basso per un indice. Quindi la mia ipotesi migliore è che in qualche modo server di SQL mancava un indice potrebbe utilizzare e l'aggiunta di questi cambiamenti dispari fatto risaltare meglio.

Ma se stai cercando di imparare il 'perché' coinvolti in modo che la prossima volta si può scrivere la query per essere più veloce, in primo luogo, non c'è davvero niente lì.

Answer 3

A WAG completo:

ho intenzione di indovinare che fpartno ha una condizione "non nullo" su di esso (in modo che il filtro aggiunto passa sempre), e che Toad capita di sapere che SQLServer non è abbastanza intelligente per rilevare che> = CHAR (0) è sempre vero. Quindi, questo suggerisce che Toad sta cercando di guidare, in modo molto obliquo, l'ottimizzatore di utilizzare qualcosa che ha fpartno in esso. Quel qualcosa potrebbe essere un indice composito (fcinvoice, fpartno) .. avete uno di quelli?

Come gli altri hanno detto, il piano di spiegare dovrebbe rivelarsi disponibile a spiegare il mistero.

Answer 4

Nessuno di questi cambiamenti hanno alcun effetto sul significato logico della query (vale a dire, sono "no ops")

L'unico effetto fisico che la COALESCE sulla clausola ON sarebbe quello di evitare che l'ottimizzatore di tentare di utilizzare un indice per ARI.FCINVOICE.

Analogamente, l'unico effetto fisico che il "> = CHAR (0)" potrebbe avere sul ottimizzatore potrebbe essere per spingere a considerare l'utilizzo di una scansione intervallo indicizzato (o anche cercare) sulla un indice che aveva ARI. [fpartno] in esso.

Quindi, la mia conclusione sarebbe che ROSPO sta cercando di manipolare l'ottimizzatore ad utilizzare un determinato indice, senza in realtà costringendo per l'utilizzo di tale indice con una SUGGERIMENTO esplicito. In realtà, questo è il tipo di intelligente come il vero problema con gli hint di ottimizzazione T-SQL è il loro dipendenze e fragilità.