Optimisation de la requête avec plusieurs jointures

j'ai cette requête .. 214 Exécution / min, 44,42 CPU moyen (ms) est-il un moyen de le rendre beaucoup plus rapide

SELECT        P.Id id0,
              P.ProgramId ProgramId1,
              P.ProgramName ProgramName2,
              P.ProgramLevel ProgramLevel3,
              P.Department Department4,
              P.Track Track5,
              P.AcademicYear AcademicYear6,
              P.StartTerm StartTerm7,
              P.Delivery Delivery8,
              P.Fee Fee9,
              P.City City10,
              P.STATE State11,
              P.StartDate StartDate12,
              P.Deadline Deadline13,
              P.DeadlineDisplay DeadlineDisplay14,
              P.ProgramType ProgramType15,
              O.Id as OrganizationId16,
              O.NAME OrganizationName17,
              P.ApplicationType ApplicationType18,
              P.Concentration Concentration19,
              P.ZipCode ZipCode20,
              P.Campus Campus21,
              P.WADisplayName WADisplayName22,
              P.UpdatedDate updateDate23,
              AF.Id InstanceId24,
              RD.Id stateId33
INTO #TempGetFullProgramSelectionInfo            
FROM    unicas_config..applicationForm AF  
  INNER JOIN UNICAS_CONFIG.. AcademicInstitution AI
           ON AF.casid=AI.casid 
  INNER JOIN UNICAS_CONFIG..Organization O 
           ON O.academicInstitutionid=AI.id   
  INNER JOIN UNICAS_CONFIG..AssociationOrg asOrg
           ON asOrg.FormId=AF.id
  INNER JOIN  UNICAS_CONFIG..Program P
           ON P.AssociationOrgId=asOrg.Id and asOrg.OrganizationId=O.id AND AF.Id = 6286
  INNER JOIN  unicas_config..ReferenceData RD 
                 ON P.STATE = RD.ValueId AND RD.ValueAbbr ='US'
  INNER JOIN  unicas_config..ReferenceDataSet RS  
           ON RD.ReferenceSetId = RS.SetId AND RS.NAME = 'LK_States'

Maintenant, si je divise en 2 requêtes

select RD.ValueId, RD.id into #temp1
from   unicas_config..ReferenceData RD
INNER JOIN  unicas_config..ReferenceDataSet RS   ON RD.ReferenceSetId= RS.SetId AND RS.NAME= 'LK_States'
where RD.ValueAbbr='US';


SELECT        P.Id id0,
              P.ProgramId ProgramId1,
              P.ProgramName ProgramName2,
              P.ProgramLevel ProgramLevel3,
              P.Department Department4,
              P.Track Track5,
              P.AcademicYear AcademicYear6,
              P.StartTerm StartTerm7,
              P.Delivery Delivery8,
              P.Fee Fee9,
              P.City City10,
              P.STATE State11,
              P.StartDate StartDate12,
              P.Deadline Deadline13,
              P.DeadlineDisplay DeadlineDisplay14,
              P.ProgramType ProgramType15,
              O.Id as OrganizationId16,
              O.NAME OrganizationName17,
              P.ApplicationType ApplicationType18,
              P.Concentration Concentration19,
              P.ZipCode ZipCode20,
              P.Campus Campus21,
              P.WADisplayName WADisplayName22,
              P.UpdatedDate updateDate23,
              AF.Id InstanceId24,
              RD.Id stateId33
INTO #TempGetFullProgramSelectionInfo            
FROM    unicas_config..applicationForm AF  
  INNER JOIN UNICAS_CONFIG.. AcademicInstitution AI
           ON AF.casid=AI.casid 
  INNER JOIN UNICAS_CONFIG..Organization O 
           ON O.academicInstitutionid=AI.id   
  INNER JOIN UNICAS_CONFIG..AssociationOrg asOrg
           ON asOrg.FormId=AF.id
  INNER JOIN  UNICAS_CONFIG..Program P
           ON P.AssociationOrgId=asOrg.Id and asOrg.OrganizationId=O.id AND AF.Id = 6286
  INNER JOIN    #temp1 RD ON P.STATE= RD.ValueId;

en utilisant la requête recommandée par Frisbee

Utilisation de la jointure par hachage

sql-server index-tuning

— sebeid
source

Combien de temps la requête doit-elle exécuter maintenant? Et pourquoi est-il exécuté 200 fois par minute? Pouvez-vous expliquer si souvent la nécessité de sauvegarder les résultats dans une table temporaire?

— ypercubeᵀᴹ

cette requête se trouve dans un SP et la table temporaire est utilisée dans la requête suivante. cette production a environ 20 K de requête par min.

— sebeid

Réponses:

Essayez ceci
Vous avez des conditions de jointure (potentiellement) mal placées

SELECT        P.Id id0,
              P.ProgramId ProgramId1,
              P.ProgramName ProgramName2,
              P.ProgramLevel ProgramLevel3,
              P.Department Department4,
              P.Track Track5,
              P.AcademicYear AcademicYear6,
              P.StartTerm StartTerm7,
              P.Delivery Delivery8,
              P.Fee Fee9,
              P.City City10,
              P.STATE State11,
              P.StartDate StartDate12,
              P.Deadline Deadline13,
              P.DeadlineDisplay DeadlineDisplay14,
              P.ProgramType ProgramType15,
              O.Id as OrganizationId16,
              O.NAME OrganizationName17,
              P.ApplicationType ApplicationType18,
              P.Concentration Concentration19,
              P.ZipCode ZipCode20,
              P.Campus Campus21,
              P.WADisplayName WADisplayName22,
              P.UpdatedDate updateDate23,
              AF.Id InstanceId24,
              RD.Id stateId33
INTO #TempGetFullProgramSelectionInfo            
FROM       UNICAS_CONFIG..Organization O                 
INNER JOIN UNICAS_CONFIG..AcademicInstitution AI
            ON AI.id = O.academicInstitutionid        
INNER JOIN unicas_config..applicationForm AF
            ON AF.casid = AI.casid  
           AND AF.Id = 6286   
INNER JOIN UNICAS_CONFIG..AssociationOrg asOrg
            ON asOrg.FormId         = AF.id
           and asOrg.OrganizationId = O.id
INNER JOIN UNICAS_CONFIG..Program P
            ON P.AssociationOrgId = asOrg.Id 
INNER JOIN unicas_config..ReferenceData RD 
            ON RD.ValueId = P.STATE  
           AND RD.ValueAbbr ='US'
INNER JOIN unicas_config..ReferenceDataSet RS  
            ON RS.SetId = RD.ReferenceSetId   
           AND RS.NAME = 'LK_States'

Si #temp a des index, triez celui qui a le plus de sens

Si cela n'améliore pas la réponse, forcez simplement une jointure de hachage sur tous
Utilisez toujours la sélection dans ma réponse - ajoutez le HASH à la requête ci-dessus

INNER HASH JOIN

— paparazzo
source

j'ai essayé votre requête mais il n'y a pas beaucoup d'amélioration. Je sais également qu'il n'est pas recommandé d'utiliser INNER Hash Join in Production. De plus, je n'ai pas compris ce que vous entendez par "Toujours utiliser la sélection dans ma réponse"

— sebeid

Pas beaucoup d'amélioration - est-ce une mauvaise chose?. Non recommandé d'utiliser INNER Hash Join en production? Où avez-vous entendu cela? Pourquoi n'essayez-vous pas de sourire?

— paparazzo

a ajouté le plan d'exécution à .. cette requête consomme le plus de CPU et d'E / S en production. sur la base du nombre,

— j'obtiens

stackoverflow.com/questions/800124/… .. mais je vais essayer et vous le faire savoir. merci

— sebeid

AF.Id = 6286 n'est pas codé en dur dans la requête, c'est un paramètre passé au SP .. je viens d'utiliser ce numéro pour les tests

— sebeid

Essayez de créer l'index suivant (en supposant qu'il n'existe pas déjà)

CREATE INDEX ix_Organization_academicInstitutionid
    ON Organization(academicInstitutionid, Id) INCLUDE (Name)

— Kenneth Fisher
source

il existe un Index Non Clustered sur Academic Institutionnel et un Index Clustered sur ID ..

— sebeid

Plus précisément, y a-t-il une inclusion (nom) dans l'index sur l'institutionnalisme universitaire?

— Kenneth Fisher

oui le nom est inclus aussi .. est-ce important que ce soit 1 index ou 2 index

— sebeid

Vous voulez dire que vous avez l'index clusterisé sur id et le second sur academicstitutionndId include (nom)? J'irais de l'avant et créerais l'index composite. Si vous regardez vos plans, la plupart d'entre eux font des recherches d'index cluster. L'idée est d'essayer d'en faire une recherche d'index à la place.

— Kenneth Fisher

Avant d'apporter une modification au script, effectuez simplement une reconstruction d'index sur toutes les tables impliquées et voyez s'il y a une augmentation significative. (au moins, faites une reconstruction des statistiques au niveau de la table avec une analyse complète)

[Programme] semble être une grande table, assurez-vous que P.AssociationOrgId est indexé.

— jyao
source

je reconstruis les statistiques tous les jours et tous les index ont été reconstruits

— sebeid