Sql Server requête de requête

Question

J'ai une procédure stockée sur une base de données occupée qui sort constamment haut dans la liste des requêtes coûteuses (d'une certaine manière). La requête est très simple, elle prend un seul paramètre (@ID, int) qui est la clé primaire de la table, et sélectionne l'enregistrement qui correspond à cet ID. La clé primaire est un champ d'identité avec un index clusterisé, donc je suis perplexe quant à la façon d'optimiser cela plus loin?

La requête est la suivante

CREATE PROCEDURE [dbo].[P_Call_Get] 

    @ID int = null 

AS 

    select ID, 
     AppID, 
     AgentID, 
     AgentLogin, 
     Ext, 
     VDN, 
     VDNName, 
     Skill, 
     SkillName, 
     CallFrom, 
     TelNoFrom, 
     ParentCallID, 
     CallStart, 
     ACWStart, 
     CallEnd, 
     Outcome, 
     StageID, 
     TxTo, 
     TxSuccess, 
     ServiceID, 
     DiallerID, 
     CRC, 
     TSCallID, 
     CallDirection, 
     [Manual], 
     CallBackAgent, 
     CallBackDateTime, 
     Notes 
    from P_Call 
    where (ID = @ID or @ID is null) 

Je ne sais pas la meilleure façon d'afficher le plan d'exécution - tout ce qu'il montre est que 100% de l'opération est repris par l'index cluster scan

Answer 1

Je pense qu'en utilisant where (ID = @ID or @ID is null) vous obtenez un plan sous optimal. Divisez ceci en 2 requêtes séparées de sorte que dans le cas où @Id n'est pas nul, il le recherchera directement et vous obtiendrez une recherche plutôt qu'une analyse apparaissant dans le plan. Vous pourriez peut-être créer une vue avec les colonnes dont vous avez besoin pour éviter la répétition (ie de la requête sans clause where)

select ID, 
    AppID, 
    AgentID, 
    AgentLogin, 
    Ext, 
    VDN, 
    VDNName, 
    Skill, 
    SkillName, 
    CallFrom, 
    TelNoFrom, 
    ParentCallID, 
    CallStart, 
    ACWStart, 
    CallEnd, 
    Outcome, 
    StageID, 
    TxTo, 
    TxSuccess, 
    ServiceID, 
    DiallerID, 
    CRC, 
    TSCallID, 
    CallDirection, 
    [Manual], 
    CallBackAgent, 
    CallBackDateTime, 
    Notes 
from P_Call 

Answer 2

peut vous utilisez la partition de table. il peut résoudre le problème.

Answer 3

Essayez de nettoyer le cache procédure et des tampons mémoire:

DBCC DROPCLEANBUFFERS 
DBCC FREEPROCCACHE 

Ce faisant, avant tester les performances de votre procédure empêchera l'utilisation des plans d'exécution mis en cache et du cache des résultats précédents.

Answer 4

Combien de lignes y a-t-il dans la table? Vous réalisez qu'un "scan d'index en cluster" = analyse de table complète.