amélioration du temps de réponse de la requête du serveur sql

Question

J'ai une table qui contient environ 400 000 enregistrements et qui est appelée sur la page d'accueil du site intranet. Aux heures de pointe, nous pouvons avoir 300-400 utilisateurs simultanés. L'outil SQL Profiler donne la sortie suivante.

• CPU: 406
• lit comme suit: 32446
• Durée: 397

J'indexé les domaines impliqués dans la clause 'où'. Existe-t-il un moyen d'améliorer le temps de réponse?

Que faut-il faire pour réduire les lectures de disque? Configuration du serveur: Windows 2003 64 bits, SQL Server 2005 64 bits SP2, .NET 2.0.

Ajout de la requête et de la définition de table ci-dessous. Il y a environ 40 autres champs que je n'ai pas ajoutés ici pour des raisons de simplicité. Les champs qui sont principalement varchar ne sont pas utilisés dans la clause where. Ils sont juste là pour apparaître sur la page. Il y a quelques champs (5-6) qui ne sont actuellement pas utilisés mais je les ai laissés dans la requête car ils seront requis plus tard. Devrais-je les enlever maintenant alors? cela améliorerait-il le temps de réponse?

Recherche

SELECT 
    u.[PeopleKey], 
    u.[EnterpriseId], 
    u.[PersonnelNbr], 
    u.LastName, 
    u.FirstName, 
    u.MiddleName,  
    cc.WorkForceCd AS CareerCounselorWorkForceCd,      
    cc.WorkForceDesc AS CareerCounselorWorkForceDesc,      
    cc.WorkGroupCd AS CareerCounselorWorkGroupCd,     
    cc.WorkGroupDesc AS CareerCounselorWorkGroupDesc,     
    cc.CareerLevelCd As CareerCounselorCareerLevelCd,    
    cc.CareerLevelDesc AS CareerCounselorCareerLevel,    
    CL.NextLevelCD as nextCareerLevelCd 
FROM 
    [User] u 
    LEFT JOIN [User] cc ON 
     u.[CareerCounselorPeopleKey] = cc.PersonnelNbr 
    Left JOIN [CareerLevel] CLON 
     u.WorkForceCd= CL.WorkForceCd AND 
     u.CareerLevelCd = CL.LevelCd 
WHERE 
    u.PeopleKey = <integer> 

[CareerLevel]

ID int 4 [Primary Key - clustered index] 
Description varchar 150 
WorkforceCd varchar 4 
LevelCD varchar  10 
NextLevelCD varchar 10 

[Utilisateur]

PeopleKey int 4 [Primary Key - clustered index] 
EnterpriseId varchar 50 [non clustered index] 
PersonnelNbr varchar 8 [non clustered index] 
FirstName varchar 40 
LastName varchar 40 
MiddleName varchar 40 
CareerCounselorPeopleKey int 4 
CareerCounselorPersonnelNbr varchar 8 
CareerCounselorName varchar 50 
CapabilityCd varchar 5 
CapabilityDesc varchar 25 
WorkforceCd varchar 4 
WorkForceDesc varchar 40 
WorkGroupCd varchar 4 
WorkGroupDesc varchar 50 
CareerLevelCd varchar 10 
CareerLevelDesc varchar 50 

Answer 1

Pouvez-vous publier le schéma de table et les définitions d'index? À quoi ressemblent les requêtes? La quantité de lectures suggère des opérations d'E/S massives - donc peut-être en raison de vos configurations de table et d'index et/ou de la façon dont vous interrogez, même si vous avez des index, ils ne sont pas utilisés.

Exécutez-vous régulièrement des plans de maintenance dans la base de données? Par exemple. vos indices sont-ils réorganisés et/ou reconstruits lorsque la fragmentation de l'index devient trop élevée?Vous pouvez toujours utiliser l'assistant d'optimisation de la base de données SQL pour obtenir des conseils sur l'optimisation de certaines requêtes ou, mieux encore, collecter des données d'utilisation réelles à l'aide d'une trace SQL et les analyser pour d'éventuelles étapes d'optimisation.

Marc

Answer 2

Quelle est votre base de données et comment beaucoup de RAM avez-vous sur cette boîte? Vous mentionnez des index sur les champs impliqués dans la clause 'where' ... vos colonnes d'index sont-elles placées dans le même ordre que vos colonnes where clause?

Si vous exécutez le plan d'exécution de la requête dans sql management studio, voyez-vous des analyses de table (vous souhaitez rechercher)? Si vous voyez des analyses, il se peut que vous manquiez d'index.

Quelle est votre clé primaire/index clusterisé? Pouvez-vous changer vos recherches pour utiliser l'index clusterisé? C'est toujours votre itinéraire le plus rapide vers vos données.

Espérons que ça aide!

Answer 3

Jetez un oeil à la SQL Server Performance Dashboard. Si vous avez des problèmes évidents, ils vont apparaître là-bas.

De même, vous ne devez pas simplement ajouter des index sans analyser le plan d'exécution des requêtes (et voir ce qu'il recherche).

Answer 4

Rejoindre la partie gauche - toutes ces colonnes: ON [CareerCounselorPeopleKey] = cc.PersonnelNbr Left JOIN [CareerLevel] CL ON u. WorkForceCd = CL. WorkForceCd ET u. CareerLevelCd = CL. LevelCd

Comme votre clause WHERE, la clause ON était pour les relations clés évidentes!

Ainsi, les colonnes de graisse marquées doivent être indexées aussi ...