1
votes

Requête de sélection simple exécutée pour toujours

Une simple Select SQL est une requête qui s'exécute indéfiniment pour un ID particulier dans SQL Server 2012.

Cette requête s'exécute indéfiniment; il doit renvoyer 10000 lignes:

select * 
from employees 
where company_id = 12

Si je change la requête en

select * 
from employees 
where company_id = 34

, elle renvoie 7000 lignes très rapidement. / p>

Employés est une vue créée en joignant différentes tables.

Peut-il y avoir un problème dans la vue?

sql sql-server

3 commentaires

Y a-t-il un plan d'exécution différent? Si oui, merci de le publier.

Aucune différence dans le plan d'exécution. C'est la même table avec un ID différent

Publiez le détail de la table jointe (vue), il sera beaucoup plus simple de déterminer le problème

3 Réponses :

1
votes

Une possibilité est que vous ayez une très grande table. Une telle requête analyse probablement les tables entières et renvoie des lignes qui correspondent au fur et à mesure qu'elles sont rencontrées.

Je suppose que les lignes de la société 12 sont rencontrées avant les lignes de la société 34.

Si tel est le cas, un index sur (company_id) devrait vous aider.

Il peut également y avoir d'autres causes. Voici deux autres possibilités:

Conflit pour les lignes avec company_id 34 qui entraînent des retards dans la lecture des données (cela dépendra du niveau d'isolement que vous utilisez et de la nature des mises à jour simultanées).
Une colonne de taille illimitée qui contient de très grandes valeurs pour company_id 34 et vide ou très petite pour 12.

Il peut y avoir d'autres possibilités également.

1 commentaires

Salut Gordan, Merci pour l'explication. J'ai même changé la limite à 1 mais je fonctionnais toujours pour toujours

0
votes

Une des choses que vous pouvez faire pour accélérer le processus est d'indexer la colonne sur company_id car un index b-tree accélérerait la recherche.

0 commentaires

0
votes

Sans regarder la structure de la table et le plan d'exécution, voici quelques suggestions en dehors de ce que Gordon a déjà couvert:

Pourriez-vous créer des index sur les tables sous-jacentes qui peuvent couvrir cette requête? Cela inclurait l'index sur les colonnes «recherchées» et «triées» (jointures, clause where, order by, group by, distinct) et inclurait les colonnes SELECTED dans la partie INCLUDE des index (dans le cas d'un index rowstore non clusterisé)? L'objectif est de voir la «recherche d'index» dans le plan d'exécution.
Mettre à jour les statistiques sur les tables sous-jacentes. (Et en remarque, nous suggérons de garder les statistiques 'AUTO CREATE' et 'AUTO UPDATE' ACTIVÉES sauf si vous avez une raison de ne pas le faire automatiquement dans votre application)
Souhaiterait également savoir à quelle date la dernière défragmentation a été effectuée sur le serveur. Une défragmentation prolongée pourrait être une très bonne raison pour laquelle vous pourriez rencontrer ce genre de problèmes sur certaines valeurs, en particulier sur une table sur laquelle de nombreuses opérations d'écriture se produisent.
Exécutez à nouveau la requête. Même si vous ne disposez pas des informations appropriées sur le n ° 3 ci-dessus, vous pouvez essayer d'exécuter la requête en ignorant l'étape 3.
Lors de l'exécution de la requête, vérifiez les statistiques d'attente dans le serveur en interrogation sur dmvs: sys.dm_os_wait_stats et sys.dm_tran_locks. S'il te plaît vérifier si l'attente est due à CXPACKET (attend en raison d'autres processus) ou PAGEIOLATCH (lecture à partir du disque que de la RAM) ou des verrous. Il est le point de départ de l'enquête qui vous donnera le la cause fondamentale et vous pouvez alors prendre les mesures appropriées en conséquence.
Une vérification rapide supplémentaire peut être: vérifier la «RAM disponible» dans le gestionnaire de tâches du serveur. Veuillez vous assurer que votre RAM SQL Server n'est pas utilisée par d'autres applications / sessions inutiles.

0 commentaires