Le plan d'exécution SQL affiche un «nombre réel de lignes» supérieur à la taille de la table

J'ai un plan d'exécution pour une jointure assez complexe qui montre qu'un index est recherché sur une table avec le "nombre réel de lignes" lu ~ 70,000, alors qu'il n'y a en fait que 600 lignes dans le tableau au total (le nombre estimé des rangées est seulement 127).

Notez que toutes les statistics sont à jour et que les parameters d'input de la requête sont exactement les mêmes que ceux qui ont été entrés lors de la compilation du proc.

Pourquoi le nombre réel de lignes est-il si élevé et que signifie réellement le nombre "nombre réel de lignes"?

Ma seule théorie est qu'un nombre élevé de lignes est lié aux loops nestedes, et que cette search d'index est en cours d'exécution un certain nombre de fois – le "nombre réel de lignes" représente réellement le nombre total de lignes sur toutes les exécutions. Si tel est le cas, le nombre estimé de lignes signifie-t-il également le nombre total de lignes sur toutes les exécutions?

ActualRows count le nombre de fois que GetNext () a été appelé sur un opérateur physique.

Vous devriez aussi regarder ActualRebinds, ActualRewinds et ActualEndOfScans pour avoir une idée du nombre de fois que la boucle interne a été réévaluée:

Une reliure signifie qu'un ou plusieurs des parameters corrélés de la jointure ont changé et que le côté interne doit être réévalué. Un rembobinage signifie qu'aucun des parameters corrélés n'a changé et que l'set de résultats interne antérieur peut être réutilisé.

le nombre réel de valeurs de lignes est le résultat de toutes les valeurs traitées pour ce nœud dans le plan exec. donc oui il prend en count les loops nestedes jointes.