Dans l'extrait de plan de requête suivant, il semble évident que l'estimation de ligne pour l' Concatenation
opérateur doit être ~4.3 billion rows
, ou la somme des estimations de ligne pour ses deux entrées.
Cependant, une estimation de ~238 million rows
est produite, conduisant à une stratégie Sort
/ sous-optimale Stream Aggregate
qui répand des centaines de Go de données à tempdb. Une estimation logiquement cohérente dans ce cas aurait produit un Hash Aggregate
, supprimé le déversement et amélioré considérablement les performances des requêtes.
Est-ce un bogue dans SQL Server 2014? Existe-t-il des circonstances valables dans lesquelles une estimation inférieure aux intrants pourrait être raisonnable? Quelles solutions de contournement pourraient être disponibles?
Voici le plan de requête complet (anonymisé). Je n'ai pas d'accès administrateur à ce serveur afin de fournir des sorties à partir de QUERYTRACEON 2363
ou des indicateurs de trace similaires, mais je peux être en mesure d'obtenir ces sorties d'un administrateur si cela peut être utile.
La base de données est au niveau de compatibilité 120 et utilise donc le nouvel estimateur de cardinalité SQL Server 2014.
Les statistiques sont mises à jour manuellement chaque fois que des données sont chargées. Compte tenu du volume de données, nous utilisons actuellement le taux d'échantillonnage par défaut. Il est possible qu'un taux d'échantillonnage plus élevé (ou FULLSCAN
) ait un impact.