Procédure stockée SQL Server beaucoup plus lent que le droit de requête

J'ai une table avec plus de 100MM enregistrements. La table dispose d'un index cluster et un index non-cluster.

Je peux utiliser une base de comptage à l'aide de T-SQL sur la table et il faut 1 seconde pour s'exécuter. Quand j'ai mis le même nombre exact de requêtes à l'intérieur d'une procédure stockée puis, il faut 12 secondes pour s'exécuter.

J'ai regardé le plan d'exécution de la norme de la requête et la procédure stockée et ils sont tous les deux à l'aide de l'index non-cluster.

Je ne suis pas sûr pourquoi, la procédure stockée est tellement lent par rapport à la requête standard.

J'ai lu quelques trucs à propos de réindexation dans une situation comme ça, mais je ne suis pas sûr pourquoi j'ai besoin de le faire. Aussi, il faut quelques heures pour réindexer donc je veux être sûr que cela va fonctionner.

Toute aide sur ce serait génial.

Grâce

Mise à JOUR

Voici la procédure stockée:

SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO

ALTER PROCEDURE quickCount 

@sYID INT,
@eYID INT

AS
BEGIN

SET NOCOUNT ON;


    SELECT COUNT(leadID)
    FROM dbo.leads
    WHERE yearID >= @sYID
    AND yearID <= @eYID

END
GO

et voici la requête:

SELECT COUNT(leadID)
FROM leads
WHERE yearID >= 0
AND yearID <= 99

J'ai essayé de l'exécuter sans paramètres et le PS s'exécute de façon plus rapide (1 seconde). Donc je suppose que cela a quelque chose à voir avec les paramètres.

Pouvez-vous nous montrer un peu de la SP, doe, vous pouvez passer des paramètres?
Je pense que vous aurez besoin de montrer votre requête et SP.
Il peut arriver que vous avez essayé de requête avec des constantes et de votre procédure d'utilisation des paramètres au lieu de cela constantes. Je vous suggère de créer SQLFiddle exemple ou poster quelques détails sur le schéma de requête et de/sp
Ne vous lancez à la fois contre un "froid" tampon de page? Ou dont l'un des deux ne vous lancez en premier? Je voudrais essayer de le faire DBCC DROPCLEANBUFFERS et DBCC FREEPROCCACHE avant l'exécution de l'une de ces deux - l'exécution de la différence de temps encore se produire? Ou sont tous les deux la même vitesse maintenant?
Ne compte pas autant que je sache, mais pourriez-vous essayer la plaine de la requête avec SET ANSI_NULLS ON?

OriginalL'auteur Sequenzia | 2012-10-22

  1. 16

    Essayez de changer votre SP à l'aide de copies locales des variables passées dans l'.

    Quelque chose comme

    ALTER PROCEDURE quickCount  

@sYID INT, 
@eYID INT 

AS 
BEGIN 

SET NOCOUNT ON; 
    DECLARE @Local_sYID INT, 
            @Local_eYID INT 
    SELECT  @Local_sYID = @sYID INT, 
            @Local_eYID = @eYID INT

    SELECT COUNT(leadID) 
    FROM dbo.leads 
    WHERE yearID >= @Local_sYID 
    AND yearID <= @Local_eYID 

END

    J'ai trouvé que, en raison de Paramètre Snffing, un SP peut exécuter beaucoup plus lent, mais le rendement une fois que vous utilisez des copies des variables.

    Qu'est-ce que la détection des paramètres ?

    SQL Server : la détection des paramètres

    Merci pour l'aide mais j'avais déjà essayé. Il ne fait pas les choses plus vite.
    wow! merci pour cette! Je n'arrivais pas à trouver le problème dans mon SP jusqu'à ce que j'ai trouvé ce post! merci beaucoup!
    Merci

    OriginalL'auteur Adriaan Stander

  2. 4

    Comme déjà mentionné, cela pourrait être une la détection des paramètres problème. Essayez d'inclure la ligne:

    OPTION (RECOMPILE)

    à la fin de votre requête SQL.

    Il y a un article ici, en expliquant ce que la détection des paramètres est: http://blogs.technet.com/b/mdegre/archive/2012/03/19/what-is-parameter-sniffing.aspx

    OriginalL'auteur ninjaPixel

  3. 1

    Vous pouvez toujours essayer de l'exécuter comme sql dynamique:

    ALTER PROCEDURE quickCount  

@sYID INT, 
@eYID INT 

AS 
BEGIN 
    SET NOCOUNT ON;

    DECLARE @SQL VARCHAR(max)

    SELECT @SQL = '
    SELECT COUNT(leadID) 
    FROM dbo.leads 
    WHERE yearID >= '+CONVERT(VARCHAR(20),@sYID)+'
    AND yearID <=   '+CONVERT(VARCHAR(20),@eYID)

    EXEC (@SQL)
END

    OriginalL'auteur digscoop

  4. 0

    La première fois que vous exécutez la procédure stockée SQL Server devrez compiler la procédure stockée, ce qui peut prendre un certain temps. @Astander mentionné la détection des paramètres - qui est un point valide, et peut fausser vos résultats.

    De certains autres facteurs à prendre en compte sont (alors qu'ils ne devraient pas vraiment expliquer vos symptômes):

    • Vous pouvez forcer un niveau de verrouillage, par exemple WITH (NOLOCK) après le nom de la table, ce qui pourrait résoudre le problème (mais notez que vous pourriez obtenir des résultats erronés en faisant cela).
    • Vous devez mettre à jour les statistiques sur la table ou défragmenter les indices

    OriginalL'auteur ifx