J'ai une paire de tables avec une relation de capitaux définie. Il y a environ 20k rangées dans le parent et 120k + chez l'enfant. C'est la relation de base dans notre application et sa performance est essentielle de la mission.
Son performant mal: ( p>
exécutant la requête suivante est rapide et utilise mes index: P>
SELECT * FROM Parent LEFT OUTER JOIN child ON Child.ParentID = Parent.ID WHERE TransmissionDate BETWEEN '1-dec-2011' AND '2-dec-2011'
4 Réponses :
Essayez d'ajouter un index à (ceci permettra de joindre "code> rejoindre entre enfant.parentaid parent et enfant beaucoup plus efficace. Sans cela, chaque enregistrement parent nécessite une numérisation de table de l'enfant pour trouver des enregistrements avec une parentide correspondante.)
Vous devriez avoir des index ci-dessous:
1- Table Parent: Colonne1 PK-Of-Table primaire + Column2 TransmissionDate
2- Tableau enfant: colonne ParentID
Suggestions: 1- N'utilisez pas *, vous ne devez sélectionner que les colonnes requises.
2- Les deux index doivent Inclure les colonnes dont vous avez besoin. dans votre sélection.
Une question: Pourquoi la Rejoignez-la à l'extérieur gauche si tous les enfants doivent avoir un parent?
Les index que vous mentionnez sont définis, le profileur affiche une analyse d'index en cluster sur l'ID de la table des parents. Nous n'utilisons pas SELECT *, il s'agit simplement d'une pâte de copie de certains SQL utilisant des tests. De la même manière, l'extérieur gauche est un artefact de rabattage pour essayer de le rendre plus rapide - la vue de production a défini des colonnes de sortie et utilise une jointure interne. Pour une raison quelconque, l'analyseur de requête montre SQL Server reveulant à une analyse d'index sur l'ID parent, avec les paramètres sous forme de prédicat (comme s'il ignore complètement l'index de date + ID).
supprimé et recréé les index et maintenant ils sont utilisés.
Est-il possible qu'ils soient corrompus? Ils n'étaient pas fragmentés (était la première chose que j'ai vérifiée ...). Dans tous les cas, le problème a été résolu ...
Ensuite, cela ressemble à vos statistiques étaient obsolètes
Cela pourrait-il être un problème avec des statistiques obsolètes? Quel type de maintenance de la base de données effectuez-vous sur cette base de données et quelle fréquence? Si vous utilisez des scripts DB Mainting de OLA Hallengren, vous pouvez mettre à jour des statistiques pendant votre processus d'optimisation de l'index.
Cela devrait être un commentaire, cela ne répond pas à la question de l'OP.
Avez-vous mal-enlé la première déclaration? L'entretien semble manquer le premier
2011 'Salut Adam - Oui je l'ai fait. Ont nettoyé le SQL, devrait être plus clair maintenant :)
Aussi supprimé la clause «avec» de la première, restez de quelques tentatives pour déterminer ce qui se passait ...