Question

I have the following SQL query to execute in Sql Server MSSM, and it takes more than 5 seconds to run. The tables that are joined by the inner join, just a few tens of thousands of records. Why does it takes so long?.

The higher costs of the query are: – Clustered Index Scan [MyDB].[dbo].[LinPresup].[PK_LinPresup_Linea_IdPresupuesto_IdPedido] 78%. – Clustered Index Seek [MyDB].[dbo].[Pedidos].[PK_Pedidos_IdPedido] 19%

Thank you.

Declare @FILTROPAG bigint 
set @FILTROPAG = 1

Declare @FECHATRABAJO DATETIME
set @FECHATRABAJO = getDate()

Select * from(
SELECT distinct Linpresup.IdCliente, Linpresup.IdPedido, Linpresup.FSE, Linpresup.IdArticulo, 
        Linpresup.Des, ((Linpresup.can*linpresup.mca)-(linpresup.srv*linpresup.mca)) as Pendiente,
        Linpresup.IdAlmacen, linpresup.IdPista, articulos.Tip, linpresup.Linea,
        ROW_NUMBER() OVER(ORDER BY CONVERT(Char(19), Linpresup.FSE, 120) +
             Linpresup.IdPedido + CONVERT(char(2), linpresup.Linea) DESC) as NUM_REG
FROM Linpresup INNER JOIN Pedidos on LinPresup.IdPedido = Pedidos.IdPedido
               INNER JOIN Articulos ON Linpresup.IdArticulo = Articulos.IdArticulo
where  pedidos.Cerrado = 'false' and linpresup.IdPedido <> '' and linpresup.can <> linpresup.srv
        and Linpresup.FecAnulacion is null and Linpresup.Fse <= @FECHATRABAJO 
        and LinPresup.IdCliente not in (Select IdCliente from Clientes where Ctd = '4')
        and Substring(LinPresup.IdPedido, 5, 2) LIKE '11' or Substring(LinPresup.IdPedido, 5, 2) LIKE '10' 
) as TablaTemp
WHERE NUM_REG BETWEEN @FILTROPAG AND 1500   
order by NUM_REG ASC

———-

This is the new query with the changes applied:

CHECKPOINT;
go
dbcc freeproccache
go
dbcc dropcleanbuffers
go

Declare @FILTROPAG bigint
set @FILTROPAG = 1
Declare @FECHATRABAJO DATETIME
set @FECHATRABAJO = getDate()

SELECT  Linpresup.IdCliente, Linpresup.IdPedido, Linpresup.FSE, Linpresup.IdArticulo, 
        Linpresup.Des, Linpresup.can, linpresup.mca, linpresup.srv,
        Linpresup.IdAlmacen, linpresup.IdPista, linpresup.Linea
into #TEMPREP
FROM Linpresup
where Linpresup.FecAnulacion is null and linpresup.IdPedido <> ''
    and (linpresup.can <> linpresup.srv) and Linpresup.Fse <= @FECHATRABAJO 

Select *, ((can*mca)-(srv*mca)) as Pendiente
From(
    Select tablaTemp.*, ROW_NUMBER() OVER(ORDER BY FSECONVERT + IDPedido + LINCONVERT DESC) as NUM_REG, Articulos.Tip
    From(
            Select #TEMPREP.*, 
                    Substring(#TEMPREP.IdPedido, 5, 2) as NewCol,
                    CONVERT(Char(19), #TEMPREP.FSE, 120) as FSECONVERT, CONVERT(char(2), #TEMPREP.Linea) as LINCONVERT
            from #TEMPREP INNER JOIN Pedidos on #TEMPREP.IdPedido = Pedidos.IdPedido
            where Pedidos.Cerrado = 'false' 
                   and #TEMPREP.IdCliente not in (Select IdCliente from Clientes where Ctd = '4')) as tablaTemp
    inner join Articulos on tablaTemp.IDArticulo = Articulos.IdArticulo
    where (NewCol = '10' or NewCol = '11')) as TablaTemp2
where NUM_REG BETWEEN @FILTROPAG AND 1500   
order by NUM_REG ASC

DROP TABLE #TEMPREP

---

The total execution time has decreased from 5336 to 3978, and the waiting time for a server response has come to take from 5309 to 2730. It’s something.

Answer 1

I can’t imagine why you would think such a query would run quickly. You are:

• ordering the recordset twice (and once with where you are using
  concatentation and functions),
• your where clause has functions (which are not sargable) and ORs
  which are almost always slow,
• you use not in where not exists would probably be faster.
• you have math calculations

And you haven’t mentioned your indexing (which may or may not be helpful) or what the execution plan shows as the spots that are affecting performance the most.

I would probably start with pulling the distinct data to a CTE or temp table (you can index temp tables) without the calcualtions (to ensure when you do the calcs later it is against the smallest data set). Then I would convert the substrings to LinPresup.IdPedido LIKE ‘1[0-1]%’. I woudl convert the not in to not exists. I would put the math in the outer query so that is is only done on the smalest data set.